Tak morgen. Jeg hedder Mads Slott Maarlev, og jeg er projektleder her hos Følermind, og har arbejdet med data-platforme og data-management i 10 år som projektleder, og været med på den rejse, hvor vi gik fra de her store on-premise løsninger til de løsninger, vi arbejder med i dag, som blandt andet er Fabric. Og i den her scene er jeg her for at folde det ud og sige, hvilke muligheder der ligger netop i forhold til at implementere løsninger i dag med den her teknologi, fordi der er sket nogle kæmpe forandringer, og det gør netop også en stor forskel på, hvordan vi implementerer og hvad det gør for jer som kunder og som slutbrugere i forhold til de løsninger, vi leverer i dag. Lige præcis. Og vi kører jo på dansk i dag. Vi har kørt på engelsk op til i dag. Nu prøver vi noget nyt. Slice er stadig på engelsk, og jeg håber, at folk kan følge med alligevel. Men skal vi ikke bare hoppe ud i det? Ja. Så i dag, der kommer vi til at snakke om tre forskellige emner. Det første, det er, som der står, low effort, great results. Opdateringer i Fabric kan nogle gange godt drukne, for der kommer rigtig, rigtig mange ting. Nye opdateringer til Fabric. Så jeg har samlet tre lavt hængende frugter, som man kan bruge til at optimere sin platform. Så skal vi snakke om data agents. Hvad er de, og hvad kan de, og hvorfor skulle vi bruge dem? Og jeg kommer til at demo, hvordan man laver en agent, og hvordan man kan tune den til at blive bedre. Og så er det sidst ved Mads, som han lige sagde, fortælle om, hvordan Fabric-platformen har transformeret, hvordan man laver, er de publicerer data-platformen. Så lad os bare hoppe ud i det. Så. Tre ting er der kommet til Fabric. Noget er der nyt. Noget har været her i noget tid. Men fælles for dem alle tre er, at de kan optimere ens notebooks, eller ens data pipelines, nogle gange ret drastisk. Og det er result set caching, hvor at queries i ens lægehouse eller warehouse bliver, resultaterne bliver cached, så hvis man sender den samme forspørgsel til sit lægehouse eller warehouse, så kan man være heldig at ramme den her cache, i stedet for, at resultatet skal genberegnes. Og det går altså væsentligt hurtigere så at få et resultat tilbage. Så er der Automated Table Statistics. Det er egentlig ikke noget, som man skal ind og slå til, ligesom de to andre er. Det kører bare automatisk i baggrunden nu på alle nye delta-tabeller, man laver. Og det hjælper simpelthen Spark med at finde ud af, hvad den optimale query execution plan er. Altså hvordan skal den bygge den forspørgsel, som den laver for at komme frem med et resultat. Og det sidste, det har været ude i noget tid, det er Spark Native Execution Engine, som er en ny version af Spark-motoren, som drastisk kan øge performance af ens notebooks. Og fælles for de her tre, eller i hvert fald for to af dem, det er, at det kræver nærmest ingenting at slå de her ting til. Så det er virkelig lavt hængende frugter, som man kan bruge til at optimere ens platform. Så hvis vi går lidt ned i dem enkeltvis, så result set caching, som navnet antyder, det er, at den simpelthen cacher resultatet af dine TSQL queries mod dit warehouse eller lakehouse. Og det virker bare i baggrunden, at man skal ikke sætte noget konfiguration op, man skal ikke sætte noget tuning op, og den cacher egentlig bare, når den kan. Og så kan man være heldig, så at sige, at når man sender den samme forspørgsel igen til ens datakilde, at man så rammer den her cache. Og det er jo super ideelt, hvis man har en Power BI-rapport, for eksempel, der kører i Direct Query Mode, så er det en meget bedre oplevelse for brugerne, når de klikker rundt i rapporten. Fordi ideen er, at det bliver meget hurtigere at få resultatet tilbage til orden i Power BI. Og det er selvfølgelig sådan, at hvis der kommer ny data i den cache, der allerede er, så forsvinder cachen, så man risikerer ikke, at det er gammel data, man rammer på den her cache. Det er fuldstændig styret background af Fabric. Det er result set caching. Og det eneste, man skal gøre, altså den effort, man ligesom skal yde, det er, at man skal slå det til på sine tabeller i sit lakehouse eller warehouse. Så er der Automated Table Statistics. Og det her er altså bare en feature, der bare kører nu af på nye delta-tabeller, man laver. Så på alle delta-tabeller i One Lake, der kører de her Automated Table Statistics, som egentlig på samme måde hjælper Spark med at lave en optimal købeplan. ved at den samler nogle statistikker over dine data, dine kolonner. Det kunne være minimum, maksimumværdier, nolværdier, antallrækker. Gemmer dem i en paketfil. Og så når den bygger sin købeplan, så kigger den lige i den her for at se, hvordan ser data ud, hvordan kan jeg optimalt bygge min execution plan, købeplan. Og det var ikke fordi det før i tiden var svært at slå til, der skulle man lige ind og skrive stik kode for at slå det til, men nu kører det bare i baggrunden. Og Microsoft har selv lavet nogle tests, hvor de viser, at på komplekse queries, der er der altså op til 45% performance at hente her. Det kan godt være noget, der batter. Og den sidste performance optimering, det er den her Spark Execution Engine. Der er en ny version af den traditionelle Spark Engine, som virker på paket- og deltaformater. Så det vil sige, at det kræver ikke, at man omskriver sin kode eller noget som helst. Det er egentlig bare, at man slår den til for at kunne høste gevinsterne af den. Der er godt nok nogle begrænsninger ved den, men der er indbygget en fallback. Det vil sige, at hvis man i sin kode rammer nogle af de her begrænsninger, det kunne være et format, den ikke understøtter, så laver den fallback til den traditionelle Spark Engine, så ens notebook ikke bare fejler. Og som Microsoft selv skriver på deres hjemmeside, så betaler du egentlig bare mindre for det samme arbejde ved at bruge den her nye Spark Engine. Så der er ikke nogen argumenter for ikke at gøre det. Og det er faktisk ret lige til at slå den til. Nu hopper jeg lige over i mit Fabric workspace for lige at vise, hvor nemt det egentlig er. Så er jeg her i Fabric, i mit workspace. Jeg går ind i en notebook. Og så laver jeg et nyt miljø. Vi kan kalde det... Frenzy... Environment, et eller andet. Så her under Acceleration, der kan man slutere, at man vil bruge Native Execution Engine. Og så skal man så bare bruge det miljø, man har oprettet i sine notebook sessions. Man kan også skrive noget kode, sådan at man bruger koden direkte i enkelte sessions. På den måde kan man selv fine-tune, hvordan man vil bruge det. Men som sagt, der er ikke nogen nærmest enige argumenter for ikke at gøre det. Og det får altså ens notebooks til at køre væsentligt hurtigere. Det var lige tre tips til, hvordan man relativt nemt kan få sin data platform, sin notebook, sin pipelines til at køre væsentligt hurtigere. Det næste, jeg gerne vil snakke lidt om, det er Fabric Data Agents. Øh... Hvad er det? Hvorfor skal vi bruge det? Hvorfor skal vi bruge det? Og hvordan kommer man i gang med at bruge det? Så en Data Agent i Fabric, det er egentlig en Q&A-system, hvor man spørger sin agent om nogle spørgsmål til ens data, og så resonerer den et svar. Og man behøver at udkæde nogen teknisk forståelse for at bruge det her. Det skal man for at sætte op. Så hvorfor vi skal bruge det, det er selvfølgelig fordi, at det... Det minsker barrieren for alle, der har lyst til at spørge på ens data og få indsigt i ens data, uden at man nødvendigvis skal vide, hvordan man klikker rundt i en rapport, eller skal spørge analytikerne, hvilke filter skal jeg sætte for at få det her resultat osv. Der kan man spørge sin agent. Og det er sådan helt lavpraktisk, så kan man i sidste ende få ens agent til at eksistere i Microsoft Teams, sådan som man altid har den ved hånden, hvis man lige skal have de nyeste salgstal for eksempel. Der er så også nogle begrænsninger ved de her data agents i Fabric. Data agenterne, de elsker strukturerede data, så man kan faktisk ikke få den til at læse PDF'er og Wordfiler, så man kan ikke for eksempel oplåde det hele ens HR-medarbejderhåndbog, og så få den til at spytte svar ud på baggrund af det. Det er struktureret data med gode, deskriptive navne på tabeller og kolonner osv., som dataagenterne lever af. Og lad os prøve at se det i action, hvordan man kommer i gang med en dataagent, og ting, man skal være opmærksom på. Så det første, man gør her, det er, at man går ind i Fabric, vælger New Item, søger på Data Agent. Så har vi den her i Preview. Så giver vi vores dataagent et navn. Prinset Data Agent. Og så har vi faktisk en agent. Den her agent skal selvfølgelig have noget data. Man kan tilføje op til fem datakilder til ens agent. Og det kan være en blanding af leghouses, warehouses, semantiske modeller, KQL-databaser. Men kun op til fem datakilder. Jeg tager bare fat i et warehouse, jeg har forberedt til anledningen. Og vælger, hvilke tabeller i det warehouse, som min agent skal bruge som dens datakilde. Og så kan man egentlig gå i gang med at spørge sin dataagent. Om indsigt i ens data. Det her er sådan et taxa -datasæt med, hvor mange taxa-ture der har været på tværs af lande og tid og så videre og så videre. Og nu ser vi, hvordan den performer bare uden at vi har gjort noget. Vi har bare sagt, at den skal bruge det her data. Og så stiller vi den spørgsmål til vores data. Ja, den kommer med et svar. Antallet af taxa-ture i 2013 var 2,8 millioner. Og en af de smarte ting ved Fabric Data Agents er også, at man kan se, hvilke steps den går igennem for at få fat i det her svar. Nu er det et relativt simpelt spørgsmål, jeg stiller den, hvor den egentlig bare skal have fat i én tabel. Men man kan også stille den nogle mere komplicerede spørgsmål. Hvor den skal gå igennem mange steps og lave ret kompliceret SQL eller DAX for at få fat i svaret. Den kan da også håndtere, at man skriver forkert, ligesom jeg har gjort. Jeg har spurgt den efter Average Para Amount. Men det forstår den godt, at der skal være Para Amount i stedet for. Og her er et eksempel på den SQL-køy, som den danner for at få fat i resultatet. Man skal dog, eller man kan, det er en god idé, at hjælpe ens dataagent på vej. Og det kan man gøre ved, at man giver ens agent nogle instruktioner og nogle eksempel-queries. Man kan fx fortælle ens dataagent, at data er afgrænset inden for en bestemt periode, eller en bestemt lande osv. Eller at den altid skal inkludere et bestemt kolonne i den svar. Så giver vi lige et eksempel på en lidt mere kompleks forspørgsel her for at vise, at den kan godt lidt ud af boksen. Yes, nu har vi clearet chatten. Og nu stiller jeg den lige et spørgsmål om, hvor mange taxeturer der har været i 2022 for Danmark. Og jeg ved i mit dataset, at der er kun data i 2013 for USA og Kanada. Så jeg vil jo antage, at min agent ikke giver mig noget svar. Det giver mig så et svar, der godt kunne antyde, at der rent faktisk eksisterer data, bare ikke lige for Danmark i 2022. Men det kunne det sikkert vel være, fordi at Danmark bare ikke havde nogen taxeturer i 2022. Det er ikke helt klart, at Danmark slet ikke er en del af mit dataset og 2022 heller ikke er en del af mit dataset. Men det kan jeg hjælpe brugerne på vej med at forstå ved at give min agent nogle instruktioner. Og det er altså bare i plaintext, at man skriver, hvad ens data indeholder. Og sådan helt overordnet dataagenderne virker kun på engelsk. Så hvis man prøver at spørge dem på dansk, så vil den give en fejl og sige, at inputet ikke er på engelsk. Nu har jeg givet min dataagent nogle instruktioner. Spørger om det samme igen med data fra 2022 fra Danmark. Og så giver det et meget bedre svar, hvor den siger, at data er slet ikke tilgængeligt fra Danmark i 2022, fordi det er kun data fra USA og Kanada i 2013. Og på den måde kan man hjælpe sine brugere af de her dataagenter på vej, når de sender spørgsmål og sidder og chatter med ens agent. Og jeg tilføjer så lidt mere til de her AI-instructions. Jeg siger for eksempel, at hvis brugeren spørger mig noget med at gruppere per by, så skal den altid inkludere landet også, fordi det er ikke sikkert, at man lige ved, hvilket land den her by ligger i, og det kunne være rimelig essentiel information at have. Jeg har ikke sagt, hvordan den skal inkludere land. Jeg har bare sagt, at den skulle inkludere land samtidig med. Og her i det her tilfælde, der har den så valgt at konkatenere byen med landet. Der kunne jo godt være mere specifikt at sige, at det skal være en ekstra kolonne med land i stedet for. De her dataagenter, når man slipper dem løs, så skal man være rimelig sikker på, at de selvfølgelig performer godt og svarer rigtigt. Og det kan man gøre programmatisk, eller følge med i programmatisk i en notebook. Der kan man etablere det, der hedder et ground truth dataset, hvor man laver nogle basale eller nogle basis spørgsmål, som altid skal give det samme svar. Og så kan man evaluere sin agent. Det er det, jeg vil gøre i min notebook her. Evaluere sin dataagent og se, hvor præcist rammer den egentlig på de her svar. Og jeg har kun taget to basis spørgsmål med. Man kan sagtens have, jeg er faktisk ikke klar over, hvad grænsen er, men man kan oplote store dokumenter med alle de her basis spørgsmål, sådan at man kan sikre sig, at ens agent svarer rigtigt. Fordi det er jo lige så vel, som når man har en pravbererapport. Hvis tallen ikke er korrekte der, og brugerne oplever, at der ikke er korrekte talle, så falder tilliden til rapporten. Og det vil være det samme med en dataagent. Hvis den begynder at komme med nogle forkerte svar, så falder tilliden til, at ens agent i det hele taget virker. Men der kan man bruge det redskab her i en notebook til at løbende følge med i, hvor godt den performer. Og man kan også følge med i, hvilke spørgsmål den får fra brugerne, og se, hvad den returnerer svar. Og så kan man bruge de spørgsmål til at gøre ens dataagent bedre, ved fx at tilføje dem til de her example queries. eller til instruktionen og sige, at hvis brugerne spørger om det her, så mener de egentlig det her. Her er outputtet på den her evaluate data agent. Og det kan man jo over i en pravbererapport, så man løbende har noget governance og noget føling med, hvordan ens dataagent egentlig former. Og skal man så bruge sin agent i Fabric? Nå, det behøver man ikke. Nu er jeg hoppet over i Teams, hvor jeg tilføjer min dataagent. Og så kan jeg egentlig begynde, ligesom før, at stille den spørgsmål direkte fra Teams. Så det bliver noget mere spiseligt, end at man skal bevæge sig ind i Fabric-platformen og finde, hvor var det nu, agenten var osv. Men så kan man liggende her i Teams og chatte med den, ligesom hvis det var en af ens kollegaer fx. Men for at alt det her dataagent virker korrekt, så er det jo også super essentielt, at man har en god data-platform, data-platform, en god data-platform, som understøtter, at den kan give de rigtige svare. Det vil sige, at man har, hvad hedder det, valideret data, og data står korrekt, og det er beskrevet godt, og alle de her ting. Der kommer vi jo ind i dit område, Mads, med implementering af Fabric-platformen, og hvordan man gør det. Præcis. Og det er jo det, der er helt vildt fascinerende ved at arbejde inden for det her felt i de her år, men har været det i rigtig mange år. Det er jo den udvikling, der sker rent teknologisk, som bare giver os nogle muligheder i forhold til, hvordan vi som organisationer vælger at begive os ind i data management, hvis det er i det første trin, men også bevæger os videre i forhold til de tidligere valg, vi har truffet. Kan du finde mit slide? Der. Super. Fordi som regel, så starter vi jo med det setup, vi har, med den platform, vi har, om det er en on-premise platform, eller om det er, vi allerede bevæger sig op i skyen, men vi skal finde ud af, hvilken retning, ønsker vi at gå med vores data platform. Typisk er der et forretningsbehov, vi ønsker, og det ikke. Det kan også være en platform, der er licensmæssige årsager ved at være forældet, og det kan være en lyst for at bare begive os ind på nye områder, som giver os nogle nye muligheder, som eksempelvis Fabricamp. Typisk så skal vi jo tage et platformvalg til at starte med. Vi skal jo finde ud af, hvad for en arkitektur er det, vi vil. Hvad er det for en forretningsværdi, vi vil opnå? Hvad er det for nogle business cases, vi skal benytte til at retfærdiggøre det her over for en bestyrelse, eller en styregruppe, eller hvem det nu er, vi ønsker at løfte det her op til? Og det er der, hvor Fabric, som i en meget pragmatisk og proof of value-fokuseret tilgang, kan give nogle værktøjer, som gør, at vi kan komme ud over stepperne hurtigt. vi kan med begrænset risici finde ud af, er det her noget for os? Er det en platform, som danner de rammer, som der skal til for, at vi ønsker at give os ind på Fabric som helhed? Samtidig så er det en platform, som er ekstremt skalerbar, som vi kan starte småt med. Vi kan starte ud med et enkelt forretningsområde, med en enkelt kilde, kan gøre os nogle erfaringer, men vi har ikke begrænset os til at starte med. Og det er jo der, hvor det er en kæmpe forskel, og det skal ikke blive sådan en historiefortælling, men vi skal ikke meget mere end de her 5 -6-7 år tilbage, hvor vi stadigvæk lavede store on-premise løsninger, hvor vi købte server ind, og satte dem ud i en kælder, og trakte nogle kabler, og var i meget højere grad låst, i forhold til de valg, vi træffede der. Men vi har allerede nu hørt bare i dag, i forhold til de her data agents, som bliver tilføjet, og hvor der kommer nye features ind, uden at vi skal gøre det store. Og det er jo det, der er helt magisk ved arbejdet inden for det her felt, med Fabric, og med de her andre nye cloudløsninger. Det er jo, at nu får vi data agents ind. Vi har også fået Plurview ind. Vi får alle mulige forskellige tilføjelser, som bliver lagt på vores platform, som vi kan slå til, hvis vi ønsker, og hvis vi har et behov, når vi har et behov, men vi er ikke tvunget til det. Så det koster os ikke noget. Vi har bare muligheden. Og det er jo der, hvor den her platform og den agilitet, det giver os i projektet, i leverancen, er helt enestående i forhold til, hvad vi kommer fra. Det er jo ligesom en platform, som netop gør, at vi tør begiver os ud i, måske eksperimentere lidt, fordi vi kan bare slukke for det, hvis der ikke er forretningsvidet. Der er heller ikke et stort buy-in til at starte med, for netop fra en bestyrelse af, som måske skal finde ud af, at det er der med agents, hvad er det for noget? Så skal vi ud og have licens, og vi skal lave installationer, og vi skal lave en masse up front, før vi finder ud af, hvad de er i natter. Det behøver vi jo ikke, fordi vi kan netop teste af relativt simpelt på det setup, vi har. Og det kan vi jo gøre hele vejen rundt i den her platform, som netop giver os den her mulighed for at være mere eksplorerende i forhold til, hvad vi vil rent forretningsmæssigt. Og samtidig så er det jo også en platform, som både kan cater til helt små virksomheder, som har et meget afgrænset rapporteringsbehov, og store virksomheder, hvor vi ønsker at opdele vores platform i måske en mere centraliseret, kombineret med en decentraliseret tilgang, hvor vi har workspaces, hvor vi deler data på kryds og tværs, hvor vi har adgangsstyring. Vi har det helt store setup, hvor vi ligesom kan fagne det. Vi kan jo bare skrue op for platformens performance, og hvad vi nu ønsker at lægge os på, og så cater vi til det. Samtidig kan den her decentralisering jo også gøre, at vi visse forskellige steder, hvis vi er en global virksomhed, har forskellige behov, og dermed kan benytte forskellige dele af platformen. Det kan være, at vi har forretningsenheder, der er mere fokuseret på AI eller machine learning, og hvad det er, vi begynder os ud i. Så kan de benytte det, og så kan det være, at der er flere eller andre områder, som er mere, kan man sige, traditionelle, og som ikke ønsker at benytte de dele, og så kan vi jo ligesom skræddersy i vores platform efter det. Så det er en ekstremt modulerbar platform, som giver os nogle rigtig fede muligheder i forhold til, hvordan vi kan bedrive vores platform, hvordan vi som virksomhed kan vokse med platformen, men også kan sætte de begrænsninger, som vi ønsker i forhold til ikke at nødvendigvis betale for det, som vi ikke bruger. Og det er jo det, der er helt essentielt ved den måde, som Fabric er strikket sammen på. Det er jo den her pick and choose, som vi kan lave undervejs, og vi kan vokse sammen med platformen. Så det har fundamentalt ændret, hvordan vi går til vores projekter, fordi det er det her værktøj, som både kan skaleres i forhold til det, vi ønsker. Vi kan vælge de forskellige dele af platformen, som er relevante for os, i forhold til den specifikke business case, der kommer frem. Det er ekstremt brugervenligt i forhold til den her sømløse integration af forskellige værktøjer. Det er nemt at bevæge sig mellem de forskellige dele, og så er den bare ekstremt fleksibel. Så det gør jo også, at vi nødder nu, at de her forretningspokke opstår, så kan vi tabe ind i det, i det omfang, vi ønsker. Der er stor transparens ind i forhold til, hvilke dele anvender vi af platformen. Hvad bruger vi dem på? Hvad koster de? Det er ret nemt at følge med i alt det der. Vi har en relativt simple pricing model, som følger alt det her. Og det gør jo, at, jamen igen, også kostsiden er visikominimeret, fordi vi ikke behøver til at starte med at lave en kæmpestor upfront-investering, som man gjorde tidligere. Nu kan vi ligesom vokse igen, også på den side, sammen med platformen. så det er en sindssygt spændende tid, ligesom at være med i udviklingen, opstarten, transformationen af forskellige dataplatformer rundt omkring, og hvor Fabric bare er en mulighed til netop, at komme det sted hen, hvor man gerne vil, men også at man gør det med en begrænset risiko, til at starte med, når du skal til at flytte ind i det nye, fra hvor du nu kommer fra. Så det er sådan en, det er ikke, der er sådan en eller anden historisk fortælling, som på en eller anden måde, bliver blandet ind i det, men der er også en masse styrker i det her, som bare er uset, og netop det her med, at så kommer data-acens lige pludselig ind. Men det er jo revolutionerende det her, i forhold til de muligheder, der ligger i platformen, og det er der bare. Altså det kommer bare, ikke? Der er det jo også vigtigt, at have historisk fortælling med, for ligesom at vide, hvor revolutionerende det egentlig er, fordi hvor kommer vi fra, hvor er vi fra det i perspektivet? Men det er jo det i hverdagen, fordi tingene går så hurtigt, så enkeltdelende er der jo bare op til, altså nogle værktøjer, som er så langt foran, det der var for fem år siden. Forretningsmodellen er omkring det, og også økonomien omkring det. Altså det hele er jo forandret. Men som Morten også kommer ned til, så handler det jo om, stadigvæk at arbejde struktureret med data. Der er noget arbejde, der skal ligge i, og have forretningsregler på plads. altså der er noget metodik og nogle ting, som vi stadigvæk skal overholde, men nu kan vi gøre det i et setup, som bare giver os en hel masse muligheder, for at trække yderligere værdi ud af vores data, og det er forarbejde, vi laver. Så det er også derfor, de af data-ations, de kommer jo til at lægge ved siden af, ens powerb-rapporter, som har et fokus, men de kan så også, altså den data, vi har dernede, kan bruges i alle mulige andre sammenhæng, hvis vi ønsker det, og når vi ønsker det. Ja. Så det var sådan lidt en bred, grundlæggende funktion, af hvad det giver os af muligheder, i en projekt sammenhæng, som jo er det, vi typisk begiver os ind i, når vi begynder at kigge ind i Fabric, som et værktøj, i forhold til at transformere, vores data management internt, i en organisation. Ja. Og super godt input, at jeg har med til Fabric Broadcasting, så det ikke bliver ren teknik, fordi det er jo også en vigtig del af, det er jo på en eller anden måde, det er jo bare et andet aspekt, på den her platform, som jo har alle de her enkelt dele, som du også fremhæver her, til kvorderne, der kommer, jamen out of the box, kommer der lige pludselig en mulighed, for at have meget hurtigere queries, og alle de forskellige andre ting, som der ligger dernede, men det er jo ligesom den samlede pakke, som man også ligesom skal have fokus på, når man skal tænke, giver det mening for os, og hvordan giver det mening, ikke? Præcis. Det var sådan set, det for os, her i Fabric Frenzy Broadcasten, så tak fordi I så med, og ja, tak for det. Ja, have en god sommer. God sommer.