#007 Was ist der Unterschied zwischen Datasets und Dataflows in Power BI?

00:00:25 Marcus 

So dann lass uns mal starten Andreas heute mit einem besonderen Thema was du ja eigentlich gewünscht hast, und zwar das Thema DataSets and Dataflows also was ist eigentlich der Unterschied? Möchtest du das einleiten? 

00:00:42 Andreas 

Ach Marcus, das ist eine ganz coole Sache, aber du kannst dir sicherlich vorstellen warum möchte ich das einführen wollen? Ich mach es mal anders. Dataflow oder DataSet? Ich würde sagen. Der Kunde hat erstmal überhaupt kein Gespür dafür warum sollte das ein Unterschied sein und was ist das eine oder das andere? Und ich muss ehrlich gestehen ich selber hab damit auch insofern immer Schwierigkeiten, weil diese Abgrenzung ist nicht jedem klar und das ist auch der Grund, warum wir uns heute hier treffen. Warum sollte ich das eine nehmen oder das andere? Welches bietet Vorteile? Welches bietet Nachteile? Und für mich ist es grundsätzlich immer so, wenn ich die Dataflows benutze, war es bis jetzt in der Vergangenheit immer so, dass es für mich den Vorteil bringt und so hab ich es den meisten, die das erste Mal damit berühren, nähergebracht das ich gesagt hab, das Ganze was du an ETL machst, also Extraktion, Transformation, Laden, das machst du jetzt nicht mehr auf deinem Laptop, sondern das macht der Cloud-Dienst für dich. Das war für mich so immer die Abgrenzung, die ich versucht habe, wenn jemand das erste Mal Kontakt damit bekommt und ich ihn nicht gleich mit in den Kellerraum nehmen möchte, wenn du verstehst, was ich sagen will. Ich möchte also ihm nicht sofort die ganze heilige Welt, dessen Da drunter zeigen, sondern erstmal ein erstes grobes Verständnis. Beim Dataset war’s für mich immer so wenn du das nimmst, dann machst du’s auf deiner Maschine hier auf deinem Laptop, PC usw. und dort ist auch die Rechenleistung erforderlich und insofern haben viele Kunden dann immer das Thema ist mein ausgestatteter Arbeitsrechner dafür auch noch geeignet oder lasse ich lieber die Finger davon? So habe ich immer diese ersten Kontakt damit versucht näher zu bringen das eine ist eher ein Teil, was du in der Cloud machst und das andere eher was du hier lokal machst und jetzt Marcus komm was Spannendes. Wenn du das dann in den Service hochlädst auch das DataSet. Dann ist es auch ein Cloud Dienst. Dann habe ich die meisten verloren so und jetzt bist du dran. Wie kann ich die wieder zurückholen? 

00:03:02 Marcus 

Ja, genau. Bei uns ist es nämlich so, dass wir immer mal als Startpunkt eigentlich das DataSet sehen. Das ist für die Kunden eigentlich das Greifbarste, was sie haben. Ja, ganz einfach, weil es alles in einer Oberfläche ist. Also sie haben Ihre Datenmodellierung direkt in der Oberfläche im Power BI Desktop Sie können darauf ihre Visuals ansetzen, die Sie haben möchten. Das ist alles schon in sich stimmig. Was aber für die meisten Leute oder für die meisten Kunden schon immer eine Frage ist, ist. Ja, habe ich dann irgendwo keine zentrale Definition für meinen Artikel oder für meinen Kunden, weil wir einfach arbeiten. Wir haben mindestens 2-3 DataSets, einen für den Vertrieb, einen für den Einkauf und einen fürs Lager und alle sprechen über Artikel, aber eben noch keine zentrale Definition für den Artikel innerhalb der DataSets und dann wünschen sich teilweise schon die Kunden eine zentrale Definition. Aber es bringt auch gleichzeitig die erste höhere Komplexität mit sich. Nämlich plötzlich muss ich 2 Prozesse getrennt voneinander modellieren können und muss es auch ggf. über verschiedenste Personenkreise kommunizieren können. Weil ich hab ja vielleicht für die einzelnen DataSets unterschiedliche Ansprechpartner und wenn sie trotzdem auf einer zentralen. Datenbasis zugreifen möchten muss auch die, die jemand entsprechenden kontrollieren, erweitern und anpassen und es geht eben noch weiter. Aktuell kann ich eben, wenn ich die neusten Lager zahlen, brauche das Lager DataSet anwerfen und es werden die Daten aus dem System geladen, wenn es eben ohne irgendeine Zwischenschicht agiert und da ist dann auch schon der neue Artikel dabei. Wenn ich das ganze aber eben ein eine zentrale Zwischenschicht reinziehe, was ja im Prinzip die Dataflows wären im Analyticsbereich. Dann muss eben auch diese Zwischenschicht aktualisiert worden sein und es muss eben auch jemand kontrollieren, also für uns ist der Punkt, dass diese Dataflows reinzubringen. Ich kann etwas zentralisieren, ich hebe aber die Komplexität für mein Projekt an. Diese Zwischenschicht bereitzustellen und das erfordert halt schon einen gewissen Reifegrad, die der einzelne Benutzer haben, weil in seinem DataSet selber ist er erstmal ziemlich frei. Entlastet, aber damit natürlich auch, wenn wir diese zentrale Zwischenschicht haben, das Vorsystem ungemein, weil eben nicht dreimal viermal die Artikel von irgendwelchen Benutzern direkt bei Vorsystem abgefragt werden, sondern eben in dieser Zwischenschicht einfach gepuffert werden. Und da, ich hab es extra mal wieder versucht mehr von der Business Seite zu betrachten, weil wir ja hier in dem Self-Service-Gedanken sind, also wie ist der Excel User gefühlt mal sich weiterentwickelt hat wir selber haben ja ehr so einen Business BI Hintergrund, da wäre es ja vielleicht das Datawarehouse gewesen, was diese Zwischenschicht gebildet hat. Jetzt deine Meinung dazu? Häufig zieht man es ja. Ist ein Dataflow ein Datawarehouse-Ersatz? 

00:06:20 Andreas 

Uuh, ich wusste, dass das irgendwann kommt, aber dass du nach so kurzer Zeit schon eigentlich die Frage stellst, die unser Gespräch manchmal auch verkürzen könnte, in diesem Fall aber will ich es versuchen. Marcus ich finde gerade diese Thematik ist das jetzt ein Datawarehouse oder ist es keins ist eigentlich die erste Antwort wäre: Ja für den schmalen Geldbeutel ist sie das und Derjenige, der schon wirklich Datawarehouse aufgebaut hat, in irgendeiner Form und wir beide haben das ja auch schon mehrfach getan. Der würde ich sagen ja, aber so richtig nicht das ist so, wie wir treffen uns morgen früh auf einer Baustelle du musst 80 Kilometer fahren und ich sage alles klar, ich schone die Umwelt, ich fahr mit dem Fahrrad und Marcus du kommst mit dem Auto. Du wirst dann derjenige, der sagt Ich bin mit dem Auto gefahren, weil ich es dann auch in der Zeit schaffe und ich sage ok, du bist jetzt und bitte, das müssen wir wohl rausschneiden du bist eine Umweltsau, aber ich bin schon gestern Abend rübergefahren, weil so schnell schaffe ich das nicht, also insofern. Ich will das mal so sagen Dataflows sind wirklich keine schlechte Sache. 

00:07:33 Andreas 

Aber sie erhöhen den Komplexitätsgrad und sie ermöglichen natürlich eine gemeinsame Datenschicht zu schaffen, die viele dann wieder nutzen können. Da hat Microsoft natürlich den Weg versucht zu schaffen, mit diesen sogenannten Common Data Model Standard Entitäten, dir so ein bisschen Anschubhilfe zu geben, dass diese Komplexität so ein bisschen verlierst, finde ich, dass du nicht Angst hast, das zu benutzen, trotzdem lösen sich diese einzelnen Bausteine, die du eigentlich so toll und Power BI hast, lösen sich wieder in einzelne Bausteine auf für mich und wenn man sich mal an die Herkunft von Power BI erinnert, dass das Ganze auch mal in Excel entstanden ist fand ich das total spannend, dass man jetzt wieder anfangen sagt du kannst das eine nehmen, das ist gar nicht so schlecht, aber jetzt möchte ich ein gesamtheitliches Datenmodell entstehen lassen. Mit diesem Werkzeug und ich biete dir das hier an und der Dataflow speichert die Daten dann ja nicht in einer SQL-Tabelle, sondern der liegt ja auch wirklich was da drunter als Basis und das ist für mich so. Etwas, was ich aber leider nicht anfassen kann und deswegen zwar weiß ich, was da drinsteckt, aber ich kann nicht rein in diesem Raum, ich steh immer kurz vor der Box, ich kann höchstens den Knopf drücken, mach mir den ETL Prozess und zeigt die Ergebnisse, die sind dann da und wie man das ja so modern sagt persistiert, die sind da, die kannst du jetzt benutzen, aber ich darf nicht in diesen Raum rein. Da, wo es eigentlich wirklich passiert und Marcus jetzt hätte ich dich gefragt. Was ist denn in diesem Raum? 

00:09:07 Marcus 

Ja, ich habe zweierlei Sachen, weil du es gerade gesagt hast wir kommen aus dieser Excel Welt damals in dieser Excel Welt gab es ja auch die Möglichkeiten, Abfragen zentral zu hosten, also da hat man eben nicht die Ergebnisse gemacht, sondern konnte im Unternehmen eben vorbereitete Transformationen, Abfragen zentral teil, sodass sie mehrere Benutzer nutzen konnten und wiederverwenden konnten ist etwas, was beim Übergang Richtung Power BI leider entfallen ist, aber dafür gibt es eben diese Dataflows, bei den Dataflows auch ganz interessant zu betrachten sind es natürlich wirklich diese einzelnen Abfrageergebnisse. Jetzt von der Begrifflichkeit ich würde mal sagen, es ist noch kein semantisches Modell, also es besteht zwischen den einzelnen Abfragen und Tabellen, die wir da haben noch keine Beziehung, also ich habe meine Artikel da, ich habe meine Kunden da, aber ich habe noch keine Beziehung zu meinem Fakten Daten, die stehen da auch als einzelne Tabellen, sondern das ist ja der nächste Schritt, der dann kommt, wenn ich Ihnen das DataSet reingehe, dass ich eben in diese verschiedensten Tabellen aus dem Dataflow reinlade und dann in diese Beziehung bringe und damit erst dieses semantische Modell aufbauen. Und du hast es ja angesprochen das Ganze ist eben in so einer abgeschlossenen Box, aber nur in den einfachsten Verfahren. Also wenn ich, mit meiner Power BI Pro Lizenz bekomme ich 10 Gigabyte Arbeitsspeicher, indem ich diese Dataflows abspeichern kann. Im Hintergrund ist, dass in einem von Microsoft gewarteten Data Lake, ich kann aber und das ist ja auch modern in der Hinsicht das Ganze umsetzen lassen, dass ich eben meinen eigenen Data Lake mitbringe, dann zahle ich eben für den genutzten Speicher hab eben nicht diese 10 Gigabyte inklusive Speicher. Aber ich kann eben dann wirklich drauf zugreifen und was ich dann eben auf einmal sehe ist, dass das Ganze im CSV Dateien gespeichert wird, die Daten. Auch sehr schön, was man eben sieht. Bei jedem Datenload wird eine CSV Datei mit einem Snapshotangabe gespeichert. Das heißt, ich kann wirklich zwischen den verschiedensten Datenladeprozessen, die ich da hatte, die einzelnen Versionen sehen und könnte auch umstellen und das was dann noch Wichtiges kommt, das ist dann eben diese Model JSON Datei, die dann eben beschreibt, aus welchem der Verzeichnisse welche CSV Datei mit Snapshot die letzte Version ist und die eben auch noch Struktur Informationen gibt, mitgibt, so dass eben dieser Dataflow, der später über das Power BI aufgerufen wird, schon mal weiß, wie es denn das Layout und aus welcher Datei muss sich die Daten laden. Und wenn ich eben jetzt irgendwo so ein Ladeprozess nicht funktioniert hatte, konnte ich in den Model JSON Datei auch reingehen und könnte ja anderen Snapshot-Datei angeben und dann würde ich halt auch alte Daten wieder bekommen. Also das technisch schon, ja ziemlich ausgefuchst, was hinter gesetzt worden finde ich sehr spannend. Besonders weil diese Dataflows ja auch mehrere Wege, also wenn wir in der Oberfläche von Power BI sind, in dem Service mehrere Wege kennen, nämlich das eine ist, dass ich selber meinen Dataflow als Ladeprozess mit Power Query aufgebaut habe. Aber wenn ich eine entsprechend gleichwertige Struktur habe, kann ich auch sagen, ein Dataflow aufsetzen, auf ein bestehendes Verzeichnis innerhalb meines Data Lakes und da ist dann eben so der Punkt, es müsste nicht mal eben dieser Datenladeprozess innerhalb von Power BI sein, der mir diesen Dataflow bereitstellt, sondern wenn ich die CSV Datei mit einer Model JSON Datei bereitstelle, da kann ich das auch als Data Flow konsumieren lassen. 

00:12:56 Andreas 

Aber Stopp, bevor, Marcus bevor du jetzt weitersprichst. Da muss ich dich wirklich kurz unterbrechen, das ist jetzt machen wir eigentlich nicht, aber ist dir was aufgefallen? Wir reden die ganze Zeit über unser cooles Self-Service-Tool? Und du bist jetzt ganz schön du, du sitzt am Verteilerkasten gerade und jetzt stell dir mal vor, der Controller, der das, was du ihm so alles beigebracht hast, soll jetzt die Strippen neu ziehen in diesem Verteilerkasten und bevor die Strippen zieht also mit Strippen meine ich jetzt den DataSet bevor die Strippen zieht, muss er jetzt erstmal alle Kabel zusammen holen, also sprich alle Stromknoten und das ist für mich der der Dataflow wo du sagst. Ist das das semantische Modell? Es ist die Vorbereitung dazu und du bist schon du warst jetzt schon bei ganz tollen Sachen, viel viel tiefer aber diese Blackbox diese Blackbox ist nichts anderes als mein ETL-Prozess. Hier sind die Daten und wie sie jetzt weiter verknüpft werden oder überhaupt wirksamer nutzbar werden, da ist quasi für mich der Dataflow zu Ende. Da hört er wirklich auf und wo du schon bist, du bist jetzt hingegangen, sagst jetzt kannst du diese Blackbox. Du kannst die Schatulle aufmachen und du siehst die ganzen Kabel, du kannst selber entscheiden, wo wir jetzt abgespeichert, das verbinde ich mit Azure ich verknüpfe das. Ist das? Und jetzt, das ist eine für mich harte Linie. Ist das noch das Self-Service was wir wollen? Ist es das, was der Fachanwender wirklich noch können soll oder ist dieses sowie der Dataflow im Standard mitgeliefert wird, Ist das etwas, was ok ist und wenn wirklich ein Techniker kommt, der mehr möchte, dass er das dann selber entscheiden kann, also für mich ist so dieses jetzt ist diese schwarze Box dort. Ich habe die Daten damit laden lassen, also der Dataflow super mit allem, was da, ich weiß da ist viel drin. Das ist so wie beim vorkonfigurierten PC, da ist eine Grafikkarte drin Mainboard alles toll habe ich nur grob definiert, so ist es ja hier auch, es funktioniert. Wenn ich jetzt was ändern will, muss ich die Schatulle aufschrauben wie beim PC übrigens und ich tausche die Grafikkarte gegen eine coole, so ist es gefühlt für mich hier auch und ich bin dann aber nicht mehr das, das ist für mich nicht mehr das, was anschalten und funktioniert, sondern da bin ich dabei, jetzt kommt der Schrauber mit dem Schraubendreher und will doch mehr, aber das ist nicht mehr Self-Service. 

00:15:34 Marcus 

Ja, ich habe noch einen Arbeitskollegen im Hintergrund, der auch gesagt Ich bin Entwickler und bei den Ganzen Self-Service-Tools bin ich immer wieder so an dem Punkt sagt er, wo ich am liebsten erst mal sehen will, wie funktioniert das eigentlich unter der Haube wo kann ich da mit meinem Schraubenzieher rein und eigentlich so ein bisschen ganz ans Limit zu fahren. Genau aber so wie du es schon sagst die die Black Box funktioniert eigentlich sehr gut und das ist auch der ursprüngliche Ansatz gewesen eben dieser Self-Service Ansatz, den finde ich aus sehr, sehr, sehr gut. Und wir haben jetzt noch gar nicht mal weiter angesprochen es ist ja sowas wie diese. Es gibt ja Premium Funktionalitäten innerhalb von Power BI auch für den Dataflow, dann mit inbegriffen, wo auch sowas wie eine inkrementelle Aktualisierung schon mit abgebildet werden kann. Auf einfachstem Self-Service Level, wo ne erweiterte Compute Engine hinter steht die das macht, was du ja schon gesagt hast das im Prinzip auf eine SQL-Server Ebene hebt und dann SQL Server im Hintergrund macht und das ist alles geblacktboxt man kann damit plötzlich auf direkte Abfragen, also mit Direct Query drauf zugreifen. Mit dem Hausmittel funktioniert das wirklich gut? Man muss dann eben die die Premium Funktionalitäten dazunehmen und ich kann das schon sehr viel erreichen, obwohl eben auch, wie es schon vorher angekündigt war, die Komplexität für den Self-Service Anwender sich erhöht hat, weil er plötzlich zwei Spielwiesen bedienen muss, nämlich einmal seine DataSet Spielwiese und zum anderen die Dataflow Spielwiese, was du eben angesprochen hattest mit dem Common Data Model. Muss ich sagen, wenn ich es selber gar nicht so der Freund von, weil ich eben gemerkt habe, ich bin in meiner Quelle in einer Datenstruktur, das ist meistens die Datenstruktur, die ich vielleicht vom Vorsystem kenne, wo ich eben sage das ist eine Kundentabelle, da gibt es die und die Felder und ich habe eigentlich ein Zieldatenformat, das ist eben das, was ich in meinem Datenmodell haben möchte und dieses Datamodel was Microsoft dann plötzlich dazwischen gibt. Da doch mal die Überlegung zu machen wie kriege ich eigentlich meine Daten aus der Quelle in das Common Data Model förmlich gepresst, um nachher aus dem Common Data Model heraus wieder mein Datenmodell raus abzuleiten. Das ist ein Schritt für mich zu viel ich, ich verstehe die Intention da drin, wenn alle in dieser Struktur arbeiten würden, dann könnte ich Datenmodelle zwischen Firmen austauschen und wir müssen immer nur gucken, dass wir im Common Data Model auf die Customer Definition zugreifen und egal, wer das Daten Modell befüllt hat, wenn er sich auch an diesem Common Data Model gehalten hat, dann wird man den Kunden wiederfinden. Aber der Mehrwert für den entsprechenden Aufwand, sehe ich im Self-Service Bereich eher weniger. Also hab ich noch nicht so die Erfahrung gemacht. Das ganze Modell hängt ja sehr stark an dem CRM Format bei Microsoft mit dran, das heißt, die Entitäten sind da sehr, also diese Elemente sind sehr, sehr gleich. Das heißt, man kann wahrscheinlich relativ einfach CRM-Daten da reinkopieren und könnte damit weiter gehen. Aber wenn man seine eigene explizite Quelle hat und hat vorher mit dieser Daten Struktur nichts zu tun gehabt. Ich glaub, ich würde diesen Schritt nicht gehen wollen. Hab ihr mit dem Common Data Model mehr Erfahrungen gemacht. 

00:19:02 Andreas 

Ja, insofern wir haben uns dem anfangs angenähert, weil es natürlich ein, es klingt, wie ein leichter Angang und wie du schon gesagt hast, dass es für. Firmen übergreifende Nutzung, wenn alle eine ähnliche Plattform benutzen, am besten ein Microsoft Werkzeug ist das total super. Das Problem dabei ist, wir haben das tatsächlich in der Produktion nie genutzt, weil jeder Kunde doch sehr individuelle Anforderungen oder angepasste Anforderungen und bevor wir einen sag mal Standardmodell nehmen. Das anzupassen, haben wir ein Modell einfach von unserem Erfahrungsschatz her aufgebaut, was deutlich leichter und schneller für uns ist als das irgendwie anders zu machen, also sprich wir haben eigene Modelle quasi damit erstellt, ohne das Common Data Model, so wie es dort ist zu nutzen. Die Idee war gut und wie immer ist es hier so wenn du dich an das hält, was dort als Standard schon vordefiniert ist und damit glücklich bist, ist es gut und bist schnell, aber wirklich fast alle Kunden komm damit so nicht klar, weil es nicht dem entspricht, was sie sich eigentlich vorgestellt haben und insofern haben wir das eigentlich immer angepriesen. Ja, in der Werbung ist es schön, aber benutzen tut es dann am Ende keiner. Das heißt, du legst dann die vordefinierten Schachteln beiseite und machst dir danach deine eigenen weil die Schnittmuster passten irgendwie nicht und insofern haben wir das weggelassen, was aber vielmehr so noch hinzu kam auch zu, die die Standard Funktionalitäten die du schon ansprach sowas o Premium angeht also auch dort nehme ich mal das Beispiel raus wenn du mit dem Standard, der dort da ist, zufrieden bist ich nehme mal das simple Beispiel inkrementelle Aktualisierung, das eine Konfektionierung da wenn du die benutzt du damit glücklich bist, funktioniert es. Genauso auch das Thema wie ich diese hybriden Tables oder ähnliches macht, wenn du mit dem Standard leben kannst, dann ist es total super und schnell eingerichtet, aber meistens ist es so, dass wir immer noch so Nuonchen drin sind, wo der Kunde sagt, ja ich hab sie verstanden, ist ok, aber bei uns ist es doch leicht anders. Dann sind wir wieder in dieser Schleife, die tolle Box, die es dort gibt, ist wirklich nicht schlecht, wenn du damit leben kannst, bist du recht schnell an einem Ergebnis dran und wenn es dir nicht ausreicht, dann bist du immer relativ schnell in den Customizing Bereich und dann wird es natürlich etwas aufwändiger, aber trotzdem ist das ja in den meisten Form möglich und wenn du dann den die Box noch aufschraubst, Marcus, dann ist alles da, die Frage ist immer wie tief muss man gehen und kann man nicht mal versuchen, diese Standardisierung, die dort drin sind, auch so zu nutzen? Ja, und gerade auch so Richtung Premium Features und ich glaub da hast du schon viele Erfahrungen mit gesammelt, was der eine oder andere an Premium Features nicht benötigt und wenn man, den automatisierten Teil oder das, was Microsoft vorkonfektioniert hat, nicht so benutzt, sondern seinen eigenen Weg geht, kann man Premium ähnlich arbeiten, nutzt aber nicht die Vorkonfektionierten Premium Features. Das finde ich persönlich nicht verwerflich. Microsoft schlägt es ja selbst vor muss ich halt nur überlegen ist man damit total glücklich oder unglücklich? Der einzige Punkt, den ich immer sehe, dabei wirklich Richtung Premium bedeutet, wenn ich wirklich Premium brauche, was das Thema Datenspeicher und Qualität auf der Rechenleistung und das finde ich total wichtig für mich. Wenn ich das brauche, ist Premium immer ein probates Mittel, um das quasi zu schaffen, also das ist für mich absolut ok und vielleicht so auch nochmal um dieses Dataflow DataSet abzugrenzen was ich total gut finde, wenn ich sage ich nehme jeden Dataflow hab ich auch das erste Mal die Chance dieses, Ich trenne den ETL Prozess vom Rest sozusagen hat für mich den Vorteil, dass könnte ein Kollege machen, der sich mit ETL gut auskennt. Ich kann also die Entwicklung auch dadurch etwas trennen. Was standardmäßig ist es ja heute so, wenn wir beide gemeinsam ein Modell erstellen wollen und Reports bauen. Marcus so richtig gut klappt das nicht, weil wenn du im DataSet baust und ich möchte da auch was mitmachen. Gemeinsam wird es nicht gehen. Also wenn wir den ETL Prozess rausziehen können, was funktioniert, ist total super, du kümmerst dich um das Daten Modellen und Reports dann haben wir zwar quasi schon 2 parallele Prozesse und dafür ist es zum Beispiel auch gut. Persönlich finde ich das gut, außer dass halt die Dataflows vielleicht nicht auf deinem Rechner laufen, sondern in der Cloud und wenn man damit leben kann, funktioniert das wirklich gut. Und wenn Microsoft nicht gerade wieder eine 09:00 Uhr Service Zeit hat, ist es von der Warte her auch da. Ja, weil da bin ich natürlich nicht mehr mit meiner Rechen Power dran, sondern ich muss mich darauf verlassen, dass der Dienst da ist und das klappt ja auch wirklich nach den Anfängen jetzt mittlerweile ziemlich gut muss ich ehrlich sagen. Also Erfahrung dazu ist zu nutzen ist gut. Die meisten Kunden scheuen diese Trennung halt in diese einzelnen Prozessschritte wenn man so will, weil es natürlich viel einfacher ist, das alles in einem zu haben. 

00:23:58 Marcus 

Ne, aber das war der Punkt, wo ich ja selber bei uns oder ist ja ein Community Tool bei entstanden mit dem Export2Dataflows angesetzt habe, eben dass ich in der Lage bin, innerhalb einer Power BI Desktop. Wir haben da Power Query, das ist sehr sehr ähnlich angesetzt, dass sich dieses Power Query aus dem DataSet raus extrahieren lassen kann und mir direkt in diesen Dataflow hochladen kann und damit im Prinzip mit meiner Arbeit weiterarbeiten kann, was dabei eben aufgefallen ist und das hast du ja auch schon angesprochen ist eben das Thema der Leistung innerhalb von einem, von einem Dataflow wenn ich eine Tabelle lade und verwende sie zweimal, würde er im Prinzip auf seinen eigenen Speicher und auch seine eigene Rechenleistung zugreifen und dann ist es ein Premium Feature, weil es dann eben eine Computed oder Link Table ist und wenn ich hingehe und sage nein, ich verlagere diese Abfrage, sodass er zweimal aus der Quelle geladen wird dann ist die Rechenleistung oder die die Last auf der Quelle abgelegt. Es wird dadurch kein Premium Feature und dann kann ich mir sowas sparen. In unserem Beispiel haben wir sowas gehabt, dass wir eben Verkäufer aus der Datenbank laden und die Verkäufe einmal als separat betrachten. Als eigene Tabelle und eben einmal aus dem Customer heraus, also aus dem entsprechenden Kunde und wenn man dafür sorgt, dass eben für beide Abfragen der Verkäufer immer direkt aus der Quelle geladen wird, dann verzichtet man eben auf das Premium Feature und kann es damit eben direkt nutzen und auch mit einer Pro Lizenz, ohne dass man da jetzt hoch stufen muss. Das ist einfach ok, ich nutze meine eigene Rechenleistung in einer Quelle, und deswegen brauche ich kein Premium Feature. Und, genau das ist, das sind ebenso ein paar interessante Sachen. Das ist eben mit Power Queries sehr, sehr gleich. Daher findet man auch Anleitungen im Internet, dass man mit Datenquellen arbeiten kann, die vielleicht gar nicht im Dataflow aufgelistet sind die, die funktionieren, einfach, weil die Abfrage Engine im Hintergrund die gleiche oder ähnliche ist. Das heißt, das kann man nutzen, aber einen Aspekt, den ich jetzt nochmal ansprechen wollte, ist der Punkt wie teilt man eigentlich sowas auf? Weil da haben wir uns sehr viele Gedanken in der Vergangenheit zu gemacht. Bei uns wir haben das ganze Mal in einem Art Multi Mandanten Szenario angesetzt, und das heißt für den einzelnen Mandant, den ich habe, habe ich einen relativ klaren Dataflow oder einen Datenladeprozess modelliert, das heißt ich weiß, welchen Kunden ich mit welchem Verkäufer innerhalb der Mandantendaten zusammenstellen kann. Aber wenn ich das plötzlich über mehrere Mandanten gemeinschaftlich in ein Datenmodell machen soll, dann müsste ich halt sehr stark iterieren und da würde eben die Komplexität des Datenladeprozesses sehr lange und wir haben uns das dann so aufgestellt und haben gesagt ok, wir trennen einfach machen einzelne Dataflows je Mandant und wir laden erstmal die Basis Daten vor und machen die Mandanten spezifische Daten, Transformationen und erst dann, wenn jeder Mandant geladen ist, können wir mit ihm innerhalb meines DataSets diese verschiedenen Mandanten zu einem großen Datenmodell zusammenführen. Das wäre zum Beispiel eine Trennung, die man machen kann. Andere Szenario was wir schon mal häufiger bedacht haben, wäre zum Beispiel Stammdaten von Faktendaten zu trennen, so dass ich eben sagen kann ich lade zu einem Zeitpunkt meine Stammdaten. Was eben ein nicht inkrementeller Datenload sein kann und ich habe eben meine Faktendaten, die ich bei Bedarf inkrementell Lade und vielleicht Fächer ich auch die Faktendaten auf für Daten, Faktendaten, die ich für mein Vertriebsauswertung haben will, Faktendaten, die für meinen Einkaufsauswertung haben will und meine Vertriebs, Einkauf, Lagerdaten, die ich auswerten möchte, weil ich es damit innerhalb meines Entwicklungsprozess auf kleinere Teilaspekte des Datenmodells schnell neu laden kann oder bei Bedarf laden kann, ohne dass ich eben einen größeren Datenladeprozess anstoßen muss. Habt ihr da Erfahrungen oder euch Gedanken gemacht? 

00:28:17 Andreas 

Ja, interessanterweise wurde das du ansprichst ähnlich, also wir haben es tatsächlich bei einem Kunden gehabt, der halt sich für eine Planungslösung entschieden, die wir ja auch quasi von unserer Firma betreut, das heißt wir haben einmal die Prozesse der Planung in einzelne Dataflows getrennt und haben wir tatsächlich auf den Weg gefehlt, dass wir gesagt haben, wir haben eigentlich unsere Strukturen, die Laden wieder ein Dataflow, die Fakten über einen weiteren, weil hier ist die Fakten sind ja meist etwas feingliedriger, also haben wir da die Möglichkeit, das weiter zu trennen in historisierte Tabelle und nicht historisierte, auch dort haben die Flows auseinander dividiert sozusagen also in einzelne Bausteine und zusätzlich dadurch, dass die erweiterten Daten, die sie dort also das war damals tatsächlich ich nehme mal das Beispiel Erdölfeld, ja, das klingt lustig ist aber so, da kommen ja andere Daten zusammen, die werden auch anders bereitgestellt, also auch über CSV, Dateien und ähnliches ne, ich bin jedem anderen in jedem Erdölfeld sieht es auf komischerweise leicht anders aus, was man liefert, auch wenn man dasselbe fordert ist halt einfach so. Und das Interessante ist dann haben wir wirklich in diese thematische Trennung mit reingenommen was wirklich total funktioniert und danach erst im DataSet eigentlich die Zusammenführung gemacht, weil dann auch eigentlich erst die Verknüpfung der Struktur erfolgt. Verknüpfung, Kombinierung so eine im Prinzip fast so ähnlich wie ihr, nur dass das hier in diesem Fall eigentlich nur ein Mandant war, wenn du den Mandant als Erdölfeld betrachtest, dann haben wir das durch diese Erdölfelder quasi bisschen getrennt, weil das ist tatsächlich so, man fordert von jedem identische Inhalte, die Strukturen, die man bekommt, sind aber von jedem komischerweise leicht anders. Aber am Ende kamen wir tatsächlich fast immer zum selben Ergebnis überein Ölfeld und insofern war das für uns okay, das hat für uns tatsächlich den Vorteil gehabt wir konnten das auch in unterschiedliche Inhalte gliedern und unterschiedlich abarbeiten, also auch parallel, das hat wirklich gut funktioniert. Insofern war auch da der Dataflow hilfreich und das DataSet also der der nachher sagt der Orchestrator, das zusammenführt, war dann wieder eine einzige Person, weil der natürlich auch die Businessanforderungen kannte, hat den Vorteil, dass wir dort auch eine Person quasi haben. Also in der Form sozusagen so gemacht. Ansonsten viel feingliedriger würde ich das nicht machen und diese Verschachtelung von Dataflow auf Dataflow, dass man immer mehrere Kaskaden hat, haben wir in der Form nicht gemacht, weil es zur damaligen Zeit war es halt nicht so leicht, das zu nutzen und man hätte ein Premium Feature nutzen und der Kunde hat sich halt damals gegen Premium entschieden, also haben wir es mit dem Pro Features gemacht und das ging eigentlich wirklich gut und ansonsten kann ich dazu immer nur sagen, der Arbeitsprozess war ja ähnlich und vielleicht nur so als Idee, was wir tatsächlich Prototypisch immer gemacht haben, was für den Kunden etwas leichter war, das wir in Power BI in Power Query, das vordefiniert haben, kurz skizziert wie sieht es dann aus und danach haben wir jetzt bitte nicht lachen. Wir haben, dadurch habe ich dich dann kennengelernt. Wir haben dein Tool benutzt, um JSON Dateien zu generieren, die wir danach dann in die Cloud hochgeladen haben, in den Dataflow. Das war quasi so dieses erste Skizzieren der Lösung, dass man das noch schnell auf seinem PC vorarbeiten konnte und dann, wenn es wirklich darum geht, ok, so könnte man das machen hat man diese konfigurierte Datei hochgeladen also JSON Datei und konnte dann dort vernünftig weiterarbeiten und nach den ersten Erfahrungen ist das dann halt später weggefallen, aber für wirklich Prototyping mal schnell machen war das in Power BI schnell gemacht und durch die Toolmöglichkeit super leicht bereitgestellt. Also ich weiß, noch bevor ich dein Tool kannte, habe ich Copy und Paste gemacht, ich hab den Code wirklich kopiert und rüber kopiert, was sehr zu belustigen bei führte, aber diese Toolmöglichkeit hat das natürlich wirklich vereinfacht und im Prinzip, ja fast schon automatisiert. Also nochmal vielen Dank ne. 

00:32:26 Marcus 

Ja, bitte dann lass uns einen Deckel drauf machen 3 Dinge für den Heimweg von der heutigen Folge ich fange mal an, also Dataflow und DataSets sind 2 wirklich getrennte Welten? Das DataSet kann selber ohne Dataflow leben. Aber das Dataflow macht dann eben im Prinzip die Zwischenschicht, um eine zentrale Ablage zu haben und erhöht damit aber auch dann die Komplexität des im Prinzip kompletten Ladeprozesses oder der BI Lösung. So den zweiten lasse ich dir. 

00:33:03 Andreas 

Das ist sehr nett, dass du wieder angefangen hast und mir natürlich das besonders leicht macht und weil ich die leichten 3 so mag, nehme ich mir raus, was ich eben schon angedeutet hatte es ist toll, dass man innerhalb dieser Plattform es schafft, relativ leicht etwas aufzubauen also Power BI Desktop nehmen und es dann leicht in den Flow zu übergeben, insofern Prototyping und danach weiterführen Dataflow ist überhaupt kein Problem. Ja, das wäre für mich so der zweite Punkt also sprich du, das ist keine Einbahnstraße, du kannst jederzeit quasi auf einer erweiterten Plattform weitermachen. 

00:33:41 Marcus 

Okay, dann nehme ich den dritten Punkt und das ist eben das Themen mit der Struktur, also wenn man dann anfängt mit den Dataflows zu arbeiten, sollte man sich genau Gedanken machen, wie man denn seine Datenladeprozesse strukturieren möchte und wie man damit vielleicht auch Problemstellung lösen möchte, weil wir es ja eben angesprochen haben und beide ja ähnlich hatten, einmal eben bestimmte Sachen wie Fakten und Historie zu trennen, gegebenenfalls aber auch unterschiedliche Datenquellen einfach schon mal voraufzubereiten, weil eben in einem Mandanten die Daten unterschied, verschiedenen Mandanten, die Daten unterschiedlich vorliegen könnten. Machen wir das als dritten Punkt? 

00:34:20 Andreas 

Finde ich super. Ich habe auch gar keinen vierten oder ich würde ihn noch nicht vierten Punkt nennen. Am Ende würde ich immer nur wieder sagen und das haben wir letzte Folge ja schon gehabt. Die Vorbereitung und die Strukturierung, auch wenn es um Namenskonvention und weitere Strukturen wie immer geht, ist ein superwichtiger Punkt. Dann kann auch Self-Service in welcher gearteten Form auch immer wirklich schnell und produktiv klappen.  

00:34:45 Marcus 

Gut. Dann bis zum nächsten Mal. 

00:34:47 Andreas 

Bis dann Marcus.