Av Techopedia Staff, 29. mars 2017
Takeaway: Vert Eric Kavanagh diskuterer forretningsintelligens med Dr. Robin Bloor og IDERAs Stan Geiger.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, velkommen tilbake igjen, det er onsdag klokken 04 øst, og de siste par årene mente det at det er på tide med Hot Technologies, ja, ja. Jeg heter Eric Kavanagh, jeg vil være din vert for dagens show. Jeg elsker dette emnet: "Health Check: Maining Healthy Enterprise BI, " det er det vi skal snakke om i dag. Det er et sted om ditt virkelig.
Så i år er det varmt - Hot Technologies var virkelig designet for å definere spesiell teknologi, og du kan forestille deg der ute i en bedriftsprogramvareverden, det er mange og mange leverandører som selger alle slags forskjellige produkter, og hva som oppstår som skjer der er disse buzzwords som slutter å bli brukt og blir kledd på av forskjellige leverandører for veldig forskjellige ting. Og så, formålet med dette showet er virkelig å hjelpe leverandørvennene våre og hjelpe publikum med å både identifisere og pakke hodene rundt hva spesifikke typer teknologier egentlig er, og hva disse ordene alle betyr når du kommer helt ned i messingstikk.
Så jeg kommer til å stå inne som en av analytikerne i dag, vi har også Dr. Robin Bloor på linjen og Stan Geiger fra IDERA. La oss bare snakke raskt om viktigheten av forretningsinformasjon og analyse bare generelt. Dette er et grunnleggende beslutnings tre, hvis du vil, eller et flytskjema bare slags snakk om hvordan du jobber gjennom saker i selskapet ditt, har diskusjoner om forskjellige temaer, setter sammen forslag og så finner du ut hva folk tror. Er de enige? Er de uenige? Hva er konsensus, hvis du har noen, og hvordan jobber du gjennom den prosessen?
Vel, alt dette er åpenbart veldig generisk, men det er en god påminnelse om prosessen der vi foreslår ideer i selskaper, tar beslutninger og deretter går videre. Og poenget er at det kreves data for hver og en av disse komponentene. Det er enda mer sant i disse dager i verden av big data, for selvfølgelig er big data som denne gigantiske sannhetsmotoren der ute. Big data er egentlig det som skjer; det er representativt for hvem som er hvor, hva de gjør, hva de kjøper, hva sosiale medier håndterer, og tweeting for eksempel. Selvfølgelig kan alt det som blir hacket - det må du passe på - men poenget er at data er referansearkitekturen, hvis du vil, for virkeligheten.
Så du vil ha data på hvert punkt i denne beslutningsprosessen. Nå er konsensus viktig. Hvis du vil ha lykkelige brukere, kan det hende at en sjef må gå mot kornet til det alle vil ha. Vi snakket bare om Steve Jobs rett før denne webcasten startet, og han var beryktet for den slags. Han har et kjent sitat der han anbefaler at folk drukner støyen de hører rundt og så holder seg til synet sitt, hvis de vet hva de gjør er riktig. Så du trenger ikke alltid enighet, men vanligvis er det en ganske god ide. Men det generelle formålet med dette lysbildet og denne kommentaren er å drive hjem viktigheten av at vi ønsker å ta beslutningene våre basert på data, ikke bare på instinkt, selv om tarmen vanligvis er veldig god til å hjelpe deg å vite hvor du vil hen, og deretter ser du virkelig ut for å validere det eller ugyldiggjøre det med dataene dine. Og jeg vil si ikke vær redd for å se deg tilbake der inne, akkurat som en fin liten markør, eller husk at når du av og til ser tilbake på at du i det minste kan få noen referanseramme og forstå hvor du har vært kommer fra og være ærlig om feilene du har gjort. Vi har alle gjort feil, det skjer.
Så hvis du har ytelsesproblemer i forretningsinformasjonssystemene dine, vel, det er det gamle uttrykket "tålmodighet er en dyd", ikke i IT-verden, kan jeg si deg akkurat nå. Hvis brukere venter lenge på at spørsmålene deres skal komme tilbake, eller hvis de ikke får rapportene sine, eroderer det tilliten, og når tilliten er borte er det veldig vanskelig å få det tilbake. Så, jeg har lagt en strek her - omtrent 40 sekunder i disse dager er som 40 minutter i mange tilfeller - hvis et spørsmål kommer til å ta 40 sekunder, glemmer folk hva de selv snakker om, hva de spurte om av dataene. Bare tenk deg i en samtale hvis du spør noen, la oss si sjefen din, du sier: "Hei, jeg vil gjerne vite hvorfor det er at vi skal ned denne ruten." Og du måtte vente 40 sekunder i en samtale å få svar? Du ville gå ut av rommet! Du skulle tro at sjefen din har mistet tankene. Så den latensen som vi har i noen informasjonssystemer, når det er ytelsesproblemer, som vil avkutte analyseprosessen, den analytiske flyten, eller som noen kaller det, samtalen du har med dataene dine. Du må få fart på disse systemene, hva du enn må gjøre for å få det til, og vi skal snakke om det i dag, det er det du trenger å gjøre, for uten den flytende ideen frem og tilbake, er du virkelig skade hele prosessen med analyse. Så, og nok en gang, kaster jeg ut denne kommentaren: manglende tillit er en stille morder. Folk løfter ikke hendene for mye hvis de ikke stoler på deg, men de vil bare se på deg sidelengs og lure på hva som skjer. Og når den tilliten er borte, vil du få en veldig, veldig vanskelig tid å få den tilbake.
Så, kunstig intelligens, vel, vi hører stadig om maskinlæring og AI og "Åh, vil det ikke løse alle disse problemene?" Robin og jeg har hørt i mange år nå om selvinnstiller databaser og alt dette morsomme - det er noe av det som skjer, men bare stille deg selv spørsmålet: hvor ofte gjør Siri det riktig for deg? Hvor ofte har Siri tilfeldigvis dukket opp og gikk: "Beklager, det fikk jeg ikke." Det var fordi jeg ikke ba deg noe. Jeg traff ved et uhell den darnede knappen. Så det er mange feil fremdeles, og forresten i venstre side, det er ASIC-brikken fra en Apple Newton - husker du valpen fra år til år siden? Det var en av de første smarte enhetene, og det var litt for lenge siden, det er som tidlig på 90- eller midten av 90-tallet jeg vil si. At Newton kom ut og det var ikke veldig bra, men det hadde visjonen; de visste hvor de skulle, men selv nå, med iPhone AI og maskinlæring, er dette vidt misforståtte konsepter, vil jeg si.
Og absolutt med hensyn til maskinlæring, kan det være veldig nyttig og faktisk kan brukes i noen av disse miljøene der du prøver å forstå hva som skjer med den komplekse informasjonsarkitekturen din, der ting går galt. Maskinlæring kan være veldig verdifull i den sammenhengen, men bare hvis den brukes på en veldig akutt måte. Så jeg var faktisk bare på en stor begivenhet ute i California, en av de store Hadoop-distributørene Cloudera hadde analytikertoppmøtet, og jeg snakket med strategisjefen deres og sa: "Du vet, det ser ut til for meg at virkelig maskinlæring gjør bare to ting: den segmenterer og den foredler. ”Som betyr at den vil gi deg forskjellige segmenter eller klynger av aktiviteter, inkludert anomalier, som vil være et segment. Og den foredler, noe som betyr at det hjelper deg å forbedre en viss type beslutning. Det klassiske eksemplet du hører om er at det er et menneske i dette fotografiet, for eksempel. Så det er noe maskinlæring kan gjøre, og det er nyttig i visse sammenhenger, når du snakker om feilsøking, fordi du kan se etter atferdsmønstre i CPU-bruk, i minnebruk, i hastighet på disken og hva diskene gjør, og alt det slags morsomme ting. Så det kan være nyttig, men det er virkelig noe som må være veldig fokusert for å generere noen verdi.
Så en av mine andre favoritt ting å snakke om - og vi ser litt på dette, tror jeg når vi tar demoen vår i dag fra IDERA - på mange måter tror jeg mennesker fremdeles lærer å snakke silisium . Det er en materialvitenskap under alt dette, og for de av dere som har gjort feilsøking og virkelig har tatt en hard titt på komplekse informasjonsarkitekturer, når du prøver å forstå hva som skjer, til og med i en Hadoop-klynge, for eksempel, du ser bare på histogrammer. Og så må du korrelere hva disse forskjellige histogrammene betyr på et bestemt tidspunkt, og det krever intelligens; som tar menneskelig intelligens og erfaring. Så jeg er ikke redd i det hele tatt for at ML, eller maskinlæring eller AI skal ta bort for mange jobber i denne verden snart. Jeg tror det alltid vil være behov for mennesker, som ærlig talt vet hva de snakker om for å hjelpe oss med å få dette til å skje.
Så la oss fortsette å gå videre. Så, hva skjer hvis du ikke er datadrevet? Dette er et kjent maleri, “The Blind Leading the Blind” - dette er ikke det du leter etter, folkens. Du vil ikke ha denne typen miljø i organisasjonen din. Så det vi ønsker er at vi ønsker at beslutningene våre skal drives av data, og vi vil at beslutningene skal bli drevet av gode data, data av god kvalitet, og det vil bare skje hvis du samler inn riktig data, hvis det er rent og pent, og hvis systemene dine kjører ordentlig, hvis BI-systemene dine er sunne, analysesystemene dine er sunne og brukerne får det de vil på en riktig måte.
Så med det skal jeg pakke sammen og overlate til den uforlignelige Robin Bloor. Robin, ta den bort.
Robin Bloor: Ok, takk for at du har gitt meg ballen. Jeg tenkte mens du snakket, Eric, jeg tenkte bare på BI, og det var en leverandørpresentasjon jeg deltok på nylig da noen bemerket at i en bestemt leverandør, som kjører et bestemt system i et stort, dårlig datavarehus de ville, på en gitt tidspunkt kan gjøre 70 000 BI-transaksjoner som ville føre til at informasjon ble presentert for mange mennesker. Det forekom meg at hvis du faktisk har den slags arbeidsmengde, og du til og med kaster bort noen få sekunder på å utføre programvaren, så vil det faktisk bli veldig dyrt, og hvis du kaster bort minutter vil det bli fryktelig dyrt. Og så husket jeg at forferdelig mye av verden kjører på regneark - det er, tror jeg de ble kalt “skyggesystemer”, var det ikke? I første omgang, der folk bare ville sette sammen systemer ved hjelp av regneark og e-post, og de ville få ting til å skje, fordi IT-avdelingen ikke kan bygge applikasjoner for alle, så de gjør det på en måte. Og mye BI, tror jeg, blir involvert i systemer som det uansett.
Uansett, etter å ha sagt det, la oss begynne å snakke om det jeg skal snakke om. BI er en tilbakemeldingssløyfe for bedriftssystemer, det er virkelig så enkelt eller så komplisert, avhengig av nøyaktig hvilken rolle det spiller i organisasjonen. Men hvis vi ser på dette er et diagram fra omtrent fire år siden, da vi prøvde på en eller annen måte å forstå hva som skjedde på siden av analysen. Men ganske mye, alt som er i ettertid, ser tilbake på hva som tidligere har skjedd, og alt som er tilsyn, når det gjelder hvordan systemet fungerer, har en tendens til å være BI. Det pleide ikke å være tilfelle at det som var forutseende, prediktiv analyse var BI, men det blir faktisk stadig mer. Eric nevnte maskinlæring, mye maskinlæring kan faktisk på en eller annen måte bare kjøres mot en strøm av data og kan gi deg forutsigbar analyse i løpet av de kommende fem minuttene, eller til og med nesten i sanntid, slik at du kan svare på en kunde, med en beregnet kunnskap om hva som faktisk skjer.
Men midten av dette diagrammet, innsiden kommer fra analyser. Det som normalt skjer er at ulike analytiske aktiviteter pekes på spesielle datasamlinger og at noe nytt læres, læres kunnskap om virksomheten. Og den kunnskapen blir deretter fanget inn i forretningsprosessene som kan komme fra den. Og vanligvis manifesteres det på en eller annen måte når BI-varsler vises, eller bare forskjellige ting blir lagt på dashbord, og så videre og så videre. Når vi faktisk gjorde dette, er det fire begreper der, og de ender med ordet "syn", som er veldig hyggelig. Men faktisk er det ikke alt innen hva folk vil gjøre, det er også problemet med optimalisering og optimalisering gir ikke enkel analyse. Det er veldig komplekst problem, og mange optimaliseringsproblemer er ikke unikt løselige. Du kan bare ha gode løsninger, du kan ikke bevise at du har en bedre løsning. Og det er et aktivitetsområde, der det foregår aktivitet, men det er mindre enn de fleste andre analytiske områder. Så folk sier at vi lever i analysetiden - det gjør vi vel i forhold til for ti år siden, men det kan gå mye lenger enn det allerede er borte.
Så begynnelsen til BI, ønsket om kunnskap oppretter brukerforespørsler, som titter analytiske prosjekter, og de analytiske prosjektene titter på datasjøer, og datasjøer pluss analytics skaper innsikt og innsikt som titter BI. Det er en historie jeg nettopp fortalte; Jeg trodde bare jeg skulle skrive det ut. Det jeg har gjort her, mener jeg, hele poenget med dette lysbildet, og faktisk de fleste av de andre lysbildene, er bare å faktisk understreke hvor kompleks virksomheten til intelligens faktisk er. Det er ikke en enkel ting, jeg kunne ha gjort akkurat denne lysbildemåten mer komplisert enn den faktisk er, men du har i bunnen her, du har eksterne data og interne data som på en eller annen måte kommer til å bli satt inn i en iscenesettelse område, som i dag er dette slags data innsjø ting, selv om ikke alle har datasjøer. Og mennesker som ikke nødvendigvis har vellykkede. Og så er det en svelgingsaktivitet og en styrende aktivitet som kreves på dataene før du virkelig kan bruke dem. Og så serverer du dataene opp, og du rapporterer om dem, eller analyserer dem, og analysen fører til handling.
Og hvis du faktisk ser på de forskjellige analysene som finnes, er dette en utrolig lang liste, men det er ikke nødvendigvis en helt omfattende liste, det er akkurat det jeg tenkte å skrive ned, da jeg faktisk opprettet dette lysbildet. Så det er mange ting som foregår i et BI-miljø som visualiseringer, OLAP, ytelsesstyring, resultatkort, dashbord, forskjellige typer prognoser, datasjøer, tekstgruvedrift, video mining, prediktive ting, det er et stort spekter av ting som går faktisk videre. Hvis du ser på det på en annen måte, bedriftens virkelighet, egentlig er dette et lignende diagram som den siste, det er bare gjort på en annen måte. Jeg skilte det du vil kalle BI fordi det er vanlig og det er kjent hva som kreves, det betyr ikke at det som faktisk skjer, er effektivt, men i det minste vil du ha regelmessige ting som skjer i, la oss si Tableau, eller i Click, eller i Cognos, det er en emnekilde, og så videre og så videre, forskjellige regelmessige rapporter eller evner vil pågå. Og så har du analyse-appene, og de er forskjellige. Fordi analyse-appene egentlig handler om å utforske data, og i mitt sinn tilsvarer det slags forskning og utvikling. Og så har du arbeidsflyt. Under arbeidsflyt kan du blande tingene dine med operative apper og kontorapper, hvis det er nødvendig - og det er bedriftens virkelighet slik jeg ser det - selv om det i de fleste organisasjoner ikke er så godt organisert.
Så BI-forstyrrelse, dette er bare et sett med ting å nevne som gjør BI vanskeligere enn det pleide å være, fordi den gamle BI-verdenen først og fremst besto av ganske rene datasett som ble fanget på en eller annen måte, sannsynligvis fra et datavarehus og matet inn i spesifikke BI-programvare. Og i disse dager snakker jeg virkelig for fem eller ti år siden, men i disse dager utvidet ikke datamengdene seg, datakildene var kjent. Hastigheten for ankomst av dataene var kjent, selv om det ofte ikke var noe BI som skulle skje raskt nok til at visse brukeres smak ville ha det. Det var ikke noen ustrukturerte data, det var nesten ikke sosiale data, absolutt ingen IoT-data, du brydde deg ikke om dataprisen. Datamaskinverdien hadde ikke parallellitet med tanke på infrastrukturen for å kunne på en eller annen måte gjøre ting ekstra raskt. Du hadde ikke maskinlæring, og antallet analytiske arbeidsmengder var ganske lite. Og alt dette er endret, datamengden nå kan vokse veldig dramatisk. Antallet datakilder fortsetter bare å øke. Ja, strømme ankomst av data veldig raskt, mange ustrukturerte data, absolutt sosiale data som vil trenge rensing, men andre data som kan trenge rensing, absolutt IoT-data, er avtalen nå.
Data proveniens er et problem, og vi bryr oss om det. Datakraften er der, noe som er pent, fordi det gjør alle mulige ting mulig, og du har fått maskinlæring nå som et fenomen som fører til mer BI-evne og nye analytiske arbeidsmengder som vil gjøre det samme. Så BI er ikke en statisk situasjon, og jeg tror det er det siste jeg kommer til å si, før jeg overlater det til Stan. Å nei, det er det ikke, det er noe annet. Fremtidens BI-landskap, tingenes internett, hendelsesstyrte arkitekturer, alt i sanntid, OK. Det er nok BI til brukeren, av brukeren, til brukeren problemene i sammendraget. Datastrømprestasjonsaktualitet, datadekning, datarensing, ferdigheter for datatilgang, visualisering, delbarhet og handlingsevne.
Så nå kan jeg gi den videre til Stan, med mindre BI-tjenesten er pålitelig og betimelig, er det ikke en tjeneste. Stan?
Eric Kavanagh: OK, Stan, jeg gir deg ballen, ta den bort.
Stan Geiger: OK. Så det jeg skal snakke om er bare bakgrunnen min. Jeg er toppsjef i IDERA innen produktstyring, og et av ansvarene jeg har er vår forretningsintelligens som tilbyr produkt. Så jeg kommer til å utvide litt på hva Robin snakket om og snakke om nøkkelområdet med forretningsinformasjon er å overvåke plattformhelsen din. Det er som han sa, nå pleide det å være der vi hadde alle disse dataene, og det ville ta flere uker å analysere og så ville vi komme tilbake med rapporter og ting. Men BI-landskapet endrer seg slik at vi kommer nærmere analyser i sanntid nå. Og i mange tilfeller faktisk sanntidsanalyse. Så jeg snakker litt om dette lysbildet, dette er bare en slags oversikt - og akkurat som en full avsløring er at jeg kommer til å snakke om det fra et Microsoft-perspektiv, men alle disse konseptene går over om BI plattformer er i Oracle, eller du bruker Informatica og Oracle, eller bare mix-modus, hybridmiljøer. Jeg skal bare bruke i referanse til Microsoft-miljøet, men dette er ganske standard.
Robin hadde et lysbilde der inne som berørte dette, er at du har kildesystemer, der jeg har alle dataene mine sittende, og nå pleide det å være disse var alt i relasjonsdatabaser og datalagring som det, men nå har vi Hadoop og internett og ting, og alle disse ustrukturerte dataene som sitter der ute, og vi kan nå ta dem med inn i denne BI-arkitekturen. Så det midterste laget der snakker litt er datalagring i aggregering; det er her vi henter inn data, vi kan rense dem, vi kan omstrukturere dem, og deretter sette inn en type datalager, og deretter ligger presentasjonslaget på toppen av det, og det er der brukerne dine får tilgang. Og vi gjør analyser av dataene i disse datalagrene, og vi gjør dashbord, og vi har Tableau til å sitte der, rapportere tjenester, sånt. Jeg ler alltid fordi jeg var en BA-arkitekt og lo alltid om Excel, for la oss innse det, Excel er fremdeles BI-verktøyet.
Så litt oversikt der, men bare for å snakke om slags plattformarkitektur, har du kildedataene dine, og jeg snakket om det i flere datalagre. Og så har jeg lagret samlet i Microsoft-verdenen. Du har SQL Server-databasen, kanskje der datavarehuset ditt er, har du kanskje datavarehuset ditt i skyen, med som datavarehus. Du har analysetjenester, som er dine OLAP-rør og sånne ting for å gjøre aggregeringer og ting rundt å se på ting på tvers av flere dimensjoner og sånt. Så har du presentasjonslaget ditt, som jeg snakket om kort, av alle disse tingene som sitter på toppen av disse datalagrene og aggregeringene. Og jeg liker alltid dette sitatet, "Du vet ikke hva du ikke vet, " som er sant. Hvis du ikke overvåker og ikke ser på hva som skjer, på alle disse områdene på BI-plattformen, hvordan vet du når du har et annet problem enn når brukerne begynner å sende deg ekle e-poster og telefonen starter ringer om hvorfor kjører ikke rapportene mine? Hvorfor tar alt så lang tid?
Så på den måten, hva du må gjøre, må du være i stand til å overvåke plattformene dine som du betjener forretningsinformasjon fra. Og i utgangspunktet delte jeg det ned i tre områder: du har tilgjengelighet, ytelse og utnyttelse. Tilgjengelighet som betyr om ressursen er tilgjengelig: er den opp eller ned? Ganske enkelt der. Men også når du ser på når du har det, kan det hende at plattformen kan være tilgjengelig, men det kan hende du har problemer der, så du må kunne identifisere grunnleggende årsaker; må du være i stand til å ha varsel og fortelle noen hva som skjer, før ting blir kritisk. Det fører også til resultatsiden, du har ting fra et ytelsesmetrisk nivå, på servernivå, der tjenestene eller BI-tjenestene, eller BI-plattformene er vert; har du ytelse på ressursnivå der jeg kanskje får tilgang til data fra et SAN, for eksempel. SAN er ressursen, nettverksressursene, du må kunne overvåke ytelsen til alt dette, for å kunne identifisere flaskehalser og holde brukerne glade, og hvis du er i et miljø der du virkelig tidsanalyse, må du kunne identifisere flaskehalser eller problemer før de begynner å skje.
Og den siste teorien er bruken: hva gjør brukerne? Hvem er koblet til BI-kildene mine? Hvem kjører hva? Hvilke spørsmål kjører de? Hvilke rapporter kjører de? Å vite denne informasjonen er med på å bestemme og utføre kapasitetsplanlegging, for eksempel. Den viser også hva som brukes i BI-miljøet. Vi hadde en kunde som de ønsket vårt overvåkningsprodukt for BI bare slik at de visste hvilke deler av BI-miljøet de brukte slik at de kunne flytte ressurser rundt. Hvis de for eksempel ikke brukte bestemte rapporter, eller bestemte kubber for analysetjenester, ville de flyttet ressurser fra det til andre områder som ble utnyttet høyt. Et annet sitat som jeg liker, jeg liker veldig gode filmer som “Tremors, ” så fortell deg filmen min, så jeg liker dette sitatet fra Burt Gummer, som ble spilt av Michael Gross, han er en slags survivalist gun fyr og han sier, han dukker opp og han trekker frem denne enorme snikskytterriflen på 50 kaliber, og en av gutta sier: "Jævla, Bert." Og han svarer med "Når du trenger det og du ikke har det, synger du en annen melodi. ”Med andre ord, vet du hva? Han var forberedt på hva som helst, og han kom forberedt på hva som helst, og det jeg mener med dette er at hvis du ikke overvåker BI-miljøet ditt fra ressurs og utnyttelse og ting jeg nettopp har snakket om, så skjønner du ikke at du trenger et verktøy eller et miljø eller struktur som overvåker det til du ikke har det. Og så skjønner du at jeg virkelig trengte det fremover, og det er sånn som mange av våre kunder er.
Så når det er sagt, vil vi gå inn på, og vi vil se på hva vi gjør her på IDERA for å løse noen av disse problemene. Og-
Eric Kavanagh: Ok, der går du, jeg ser det.
Stan Geiger: Ser du det? Greit. Så det vi har her er at dette er BI Manager-produktet vårt. Og vi overvåker at IDERA tradisjonelt har vært et selskap i SQL Server, Microsoft SQL Server miljø. Og så kjøpte vi inn Embarcadero, så nå har vi utvidet til noen andre plattformer, men BI-produktet vårt overvåker tradisjonelt BI-stabelen i Microsoft-miljøet. Og det vil være analysetjenester for flerdimensjonal og tabellanalyse, rapporteringstjenester, rapporteringsverktøy og deretter integrasjonstjenester, som er en ETL-plattform, som ligner Informatica.
Og gjennom vårt produkt kan du overvåke alle disse miljøene gjennom ett produkt, og det du ser her er det overordnede instrumentbordet, og ting å merke seg her er når jeg snakket om det varslende, det er en ting å overvåke, men det er ikke nok - du må ha en varslingsmekanisme. Med andre ord, jeg trenger å kunne varsles før ting blir kritisk. Så hva vi gjør her, det er et helt sett med beregninger som vi fanger opp som er konfigurerbare fordi avhengig av miljøet ditt, visse terskler, kan du være i orden med en tretti millisekund lesetid, i miljøet ditt. Andre miljøer kan være mer kritisk at terskelen er lavere, så det er viktig ikke bare å ha varsler, men å ha den konfigurerbar fordi miljøer er forskjellige avhengig av ressurser.
Så i utgangspunktet er dette en oversikt over alle miljøene som blir overvåket her, og jeg har tre forekomster her: ett for analysetjenester, ett for integrasjonstjenester, et for rapporteringstjenester. Og du ser at jeg har et par varsler her. Og fordi disse er røde, forteller det meg at de er kritiske, fordi jeg har flere nivåer som jeg kan stille inn varslene, og varslene kan sendes til folk som er ansvarlige for å undersøke hva problemet er. Så bare en kort stund tar vi en titt på, så kommer jeg tilbake til varslingen, så vi kan gå inn på analysetjenestene, og det er jeg sikker på at den venter på å laste her. Og i utgangspunktet, hva vi gjør, har vi en datainnsamling; den går ut der med jevne mellomrom og går ut der og samler og snapsbilder slags hva miljøene dine gjør. Så, jeg har satt meg for hvert sjette minutt, så hvert sjette minutt går det der ute og avstemmer miljøet. Jeg sov min VM en stund, så det vil ta et sekund før dette kommer opp igjen. Der går vi.
Så vi tar en titt på analysetjenestene, og så skal jeg klikke på forekomsten min her, og huske at jeg snakket om en av tingene vi overvåker er ytelse på servernivå, fordi mange mennesker har flere ting kjører på serveren deres. Jeg kan ha en database som kjører på serveren min, så vel som analysetjenester, for eksempel. Så hvis noe skjer i databasen, eller jeg har et problem på servernivå, vil det påvirke hva som skjer der. Så vi overvåker ting på tvers av serveren på servernivå, ting som hvordan disken er ytelse, og du kan se at vi fanger opp beregninger rundt alt dette. Og alt dette er konfigurerbart. Og jeg ser på hva som skjer, CPU-messig, bare og igjen, dette er på servernivå, ikke på analysetjenestenivået i eksempelet mitt her. Men faktisk på servernivå.
Og jeg kan se på ting som hva er minnet, minnets generelle bruk, for eksempel, hva er tilgjengelig? Så nå får jeg en ide om hva helsetilstanden til selve serveren er. Så kan vi begynne å se på ting som er spesielle for, i dette tilfellet analysetjenester. Jeg kan se og se hvordan for eksempel kubebehandlingen min går her, og dette gir meg et mål på helsen. Hvis jeg begynner å se at behandlingen tar lengre tid, eller det ikke er radene som ikke skrives nesten like raskt, så kan jeg begynne å se på - og dette går til korrelasjonsstykket som jeg tror Robin snakket om, er det det tar fremdeles et menneske å kunne gjøre alt dette. Vi snakker om AI, maskinlæring, men det tar fremdeles et menneske å kunne korrelere disse hendelsene rundt ting. Vi kan se på ting som hva som skjer så langt spørsmål, hvilke spørsmål som kjøres og hvor lang tid tar de? Jeg kan sortere, så jeg kan begynne å få et inntrykk av hvilke spørsmål som tar lengst mulig tid. Du kan ta en titt her på forløpt tid, jeg kan ta en titt og se OK, hva var den spørringen og hvem kjørte den spørringen på den tiden?
Så da kan jeg begynne å fortelle en historie rundt dette så langt som når jeg begynner å se at ting begynner å spike, jeg kan gå tilbake og se og se hva brukerne gjorde på det tidspunktet. Og du vil se en av tingene vi gjør er å sette inn denne tidsvelgeren her for å la deg velge et tidsvindu. Så for eksempel kan jeg gå tilbake til disse varslene, og det var faktisk en lenke på varslene som jeg klikker på, og det ville ta meg det tidspunktet da varselet skjedde. Og så kan jeg begynne å dele historien sammen, jeg kan se oh, vel, disken ble lest opp, eller hadde problemer med minnet eller hva som helst, og så kan jeg hoppe over spørringsaktiviteten på det samme tidspunktet, og jeg kan faktisk starte korrelerer hvem som kjørte hvilke spørsmål som kan ha forårsaket piggene der inne. Og så kan du begynne å gjøre ting som jeg kan begynne å stille, det er da jeg begynner å stille. Dette er som en bil, hvis du bygger en racerbil og bare slipper motoren, og starter nøkkelen kan motoren starte, men hvis jeg trenger å gå 180 mil i timen for å vinne, må jeg vite at motoren kan kjøre 100 mil i timen, og jeg trenger å gå inn dit og begynne å stille inn motoren for å kunne komme dit. Og det er det dette gjør deg i stand til å være å kunne gi deg nok informasjon til å begynne å stille inn miljøet ditt, øke helsen og produsere miljøet og effektiviteten.
Og så overvåker vi ting på tvers av minnet som er spesielt for analysetjenester, i dette tilfellet. Og det er her du kan begynne å se hvor ting kan begynne å gå galt, når du begynner å se ting som spikker over mellom minnegrensene, sånt. Den andre tingen som er god å se på, når du kjører alle typer spørsmål, vil du at data skal bli bufret, for når det blir bufret, er det i minnet og ikke trenger å lese fra disk, noe som er mye mer effektiv enn å måtte lese data fra disk. Så du kan begynne å se på ting som foregår, unnskyld meg, i datacachen for eksempel. Jeg hadde en rekke spørsmål tidligere, for å få disse dataene, og du kan se at jeg hadde mesteparten av tiden, cache-treff og oppslag overlapper hverandre, noe som er bra. Men jeg hadde en periode her hvor treffene var mye lavere enn hva oppslagene var, som forteller meg at jeg hadde noe på gang som var minneintensivt, slik at cachen ble skyllet mye raskere, så data måtte være lest fra disken. Og det kan vi se når vi ser på lagringsmotoren. Dette er samme tidspunkt som den andre grafen, og du kan se piggen der, der spørsmålene fra filen virkelig hoppet opp i løpet av den perioden. Og det betyr at data ble lest av fra disken. Nå kan jeg gå tilbake og deretter sammenhenge det med spørsmålene som kjørte, og ikke for å få alles ører til å blø, men i analysetjenester bruker det et språk som heter MDX, det er måter å skrive spørsmål mer effektivt på, så det bruker cachen mer effektivt og mindre lagring. Så det er et eksempel på å stille inn motoren, og gi deg alle delene som trengs for å kunne korrelere det.
Bare raskt kan vi også snu den andre veien, når vi ser på spørsmålene, kan vi se på øktene, hvem har egentlig forbindelse på dette tidspunktet og hva kjører de? Så denne typen gir deg motsatt syn på spørsmålene og hvem som kjører dem. Dette er hvem som er koblet sammen, og så kan jeg se hva de kjører for øyeblikket. Den andre tingen, bare for å raskt gå over, er at du kan se alle objektene i de flerdimensjonale MOLAP-kuberene mine. Og jeg kan få informasjon om det. Så for eksempel kan jeg sortere etter denne leste kolonnen, og jeg kan se at det mest benyttede objektet er tidsdimensjon og det nest mest benyttede er kundedimensjonen. Og dette hjelper mennesker som utvikler og bygger ting til mer effektivt å bygge kubene sine. Det kan være lurt å endre min partisjonsstrategi for dataene, for eksempel på disse sterkt utnyttede dimensjonene i kuben min, og det vil derfor øke ytelsen til spørsmål, for eksempel. Det kan redusere ytelsen til å bearbeide kuben, for nå har jeg flere partisjoner, men fra et brukerperspektiv kommer det til å stille inn motoren, slik at den blir mer effektiv for å bruke disse objektene.
Så gå videre, snakk om integrasjonstjenester her. Integrasjonstjenester, nevnte jeg, er en ETL-plattform i et Microsoft-miljø. Hva vi gjør her - og dette er konsistent - overvåker vi serverens ytelse, og disse ville være de samme beregningene som vi så på, fordi alle tjenestene mine kjører på den samme serveren. Men igjen, dette er en oversikt over hva som skjer på serveren. Og så kan jeg se på aktiviteten for integrasjonstjenester, ETL-prosessene mine. Så jeg kan få en ide om når disse prosessene kjørte, enten de var vellykkede eller ikke, jeg kan fremheve et bestemt kjør av en ETL-prosess, og så vil det vise meg fordelingen av trinnene i den ETL-prosessen, om den var vellykket eller ikke og hvor lang tid det tok.
Hvis jeg hadde en mislykket pakke her ETL-prosess, kunne jeg gå ned til detaljene og se feilmeldingen, og det ville vise meg hvilket trinn i den pakken der ETL-prosessen mislyktes, sammen med alle meldingene som er knyttet til den. Så det som gjør, er at det gir meg, og jeg kan få et varsel hvis det mislykkes, så hvis jeg får et varsel, kan jeg gå inn her, se, gå til det varselet, se pakken mislykkes, se på trinnene, se hvor den mislyktes, se på feilmeldingen, og jeg vet umiddelbart hva jeg trenger å gjøre for å fikse det: distribuere den på nytt og deretter starte den på nytt. Så hva dette lar deg gjøre er at vi kaller det forkortelse av vinduet mellom identifisering av problemet og løsning av problemet. Så i forrige liv, da jeg var ansvarlig for denne typen ting, hadde vi ETL-prosess som skulle kjøres om natten, for å laste inn datavarehuset vårt. Hvis jeg hadde denne informasjonen, først om morgenen da jeg kom inn, hvis noe mislyktes, kan jeg raskt adressere den og få den prosessen opp igjen for å forsikre meg om at datavarehuset var i gang og oppdateres etter den tid brukerne kom inn og begynte å få tilgang til rapportering.
Den andre tingen er at jeg har to prosesser som kjører, er å se og se hvordan det gikk over tid. Det er viktig fordi hvis jeg for eksempel begynner å se disse prosessene, for eksempel ta lengre tid, se disse tidene rampe opp, kan det hende at jeg må ta en titt på for eksempel vedlikeholdsvinduet mitt, kan det hende at jeg har ting som skjer på den serveren. . Ta for eksempel sikkerhetskopier; Det kan hende jeg har en sikkerhetskopi på gang som får prosessen til å vente til den er ferdig. Det kan hende jeg må omplanlegge eller sjonglere prosessene mine rundt ting som begynner å påvirke ETL-en.
Og den siste brikken er rapporteringstjenester. Rapporteringstjenester er Microsofts, i utgangspunktet deres virksomhetsrapporteringsverktøy. Og noen av tingene, igjen, vi kan se på ting på servernivå, vi kan se på ting på tvers av rapportserveren, rapporteringstjenesteserveren, i seg selv. Jeg har ikke så mange ting som kjører her; Jeg har noen abonnement som kjører hvert 15. minutt for å kjøre en rapport. Så du vil ikke se mange aktive tilkoblinger fordi den går på, kobler sammen, kjører rapport, kobler fra og sender den av.
Men i høye transaksjonsmiljøer der det rapporteres mye om, er det å kunne overvåke disse tingene nøkkelen. Så du kan se hvor jeg hadde ting som skjer her, så det gir deg en ganske god ide om hva, fra det faktiske service- og plattformnivået, som foregår. Og så, som jeg snakket om i lysbildene, er hvem som kjører hva og hva gjør de? Og en av kundene våre kjøpte dette produktet bare for dette stykket fordi de ønsket å vite hvilke rapporter folk kjørte, og hvem som kjørte disse rapportene. Så dette er en av tingene i denne utførelsen av rapporten som du kan se her. Jeg kan se hvilken rapport, jeg kan se alle parametere som var i den rapporten, jeg kan se hvem som kjører den, jeg kan se formatet på rapporten. Og så har jeg fått alle disse beregningene rundt det, så hvis igjen, kan jeg rangere disse tingene, for eksempel hvilken rapport som tok lengst for å hente data, og jeg kan gå rett til det og se hvilken rapport det er. Og igjen, alt dette gir meg data for å være det, for å stille inn motoren igjen. Nå kan jeg begynne å stille inn rapporteringsmiljøet mitt rundt det.
Og den siste tingen, er at jeg kan se på brukeraktiviteten, som igjen er koblet til, hva gjør de? Jeg kan faktisk, i et miljø der jeg hadde flere brukere, disse er alle sorterbare slik at jeg kan rangere, jeg kan se hvem som bruker miljøet mest. Så bare for å gå raskt tilbake og se på disse varslene. Her var det våken; Jeg kan klikke på denne lenken her, så tar den meg til grafen for det tidspunktet og viser meg hvilken som var under varsel. Så du kan se her, det er den som skyldes at det var gjennomsnittet millisekunder for å skrive, for eksempel lese og skrive. Så igjen, bare prøv å få det poenget med å identifisere problemene. Og det er veldig viktig å ha et helhetlig verktøy, ikke bare noe som ser på den ene tingen, fordi menneskets må komme inn her og korrelere disse hendelsene som skjer, så du må kunne se på hva som skjedde på det peker i tid på tvers av flere områder i det miljøet, og det er en av tingene vi gjør gjennom denne tidsvelgeren her.
Eric Kavanagh: Ja, dette er Eric her bare med et raskt spørsmål, for jeg tror du sannsynligvis slo spikeren på hodet, og det var det jeg snakket om på toppen av timen, at et menneske må komme i og tegne disse sammenhengene mellom forskjellige miljøer. Er jeg nysgjerrig på å vite, er det noe lærerikt materiale som dere kan dele, eller kanskje gjør dere et slags engasjement med folk for å hjelpe dem med å identifisere noen av disse mønstrene? Som om du hadde et veldig godt eksempel for et øyeblikk siden, om når en av disse er pigg som forteller deg at noe skjer i minnet fordi det fortsatte å prøve å dumpe minnet. Og det gir en pekepinn, men hvordan kartlegger folk denne statistikken mot problemer i den virkelige verden, er det virkelige spørsmålet.
Stan Geiger: Ja, det er et godt poeng, og en av tingene jeg bare snakket om, veikart for produktet, er at det senere i år kommer til å gi ut en versjon og en av tingene vi skal begynne å legge til er for hver av disse grafene, er en beskrivelse av hva denne grafen betyr og hvorfor du bør bry deg, og hva virkningen av dette er. Så kan du klikke på et spørsmålstegn eller noe på dette diagrammet, og deretter trekke opp et vindu som vil gi deg mye av den informasjonen og fortelle deg at dette er de mulige årsakene, dette er områdene som blir påvirket, og å veilede i du i en retning av å kunne gå i denne saken, som du sa, her er den piggen, jeg vet av min personlige erfaring hva dette betyr. Og så kan jeg begynne å gå og begynne å bore inn i et område og finne årsaken.
Nå har vi mye av det, faktisk, i vårt diagnostiske managerprodukt for SQL Server, for den faktiske databasen. Vi har mye av den typen funksjonalitet i et slikt produkt, og også har vi noen analysebout-ons til diagnostisk manager som viser deg mye raskere. Og det er her vi skal ned på veien med dette produktet.
Eric Kavanagh: Og jeg antar at det er signaturer til visse typer aktiviteter. Lar dette verktøyet deg identifisere når en bestemt type hendelse fant sted og katalogisere det, slik at det over tid kommer til å gjenkjenne et lignende mønster nedover linjen og hjelpe deg med å finne ut om det er en ny bruker, for eksempel å bruke samme verktøyet? Hjelper deg å forstå, åh, dette er fordi disse serverne gikk ned eller fordi denne regionen gikk ned? Er det noen måte å katalogisere underskrifter på problemer, slik at du enkelt kan identifisere dem senere?
Stan Geiger: Nei, faktisk, men det er faktisk et interessant konsept, for det er nesten som, hva er det - prinsippkomponentanalyse, antar jeg - der du identifiserer mønstre og logger de mønstrene, og hvis du ser dem igjen kan du gå tilbake og se, OK, dette var årsaken på det tidspunktet. Ja, det er noe, det er ikke på veikartet, men det er noe jeg har tenkt på fra produktstyringssynspunktet.
Eric Kavanagh: Jeg kan tenke meg det. Å, fortsett.
Stan Geiger: Nei, det hadde jeg tenkt å si - og vi får mange forespørsler, for jeg vet ikke hva din erfaring er - men det vi finner er at DBA-er kjenner til databaser som baksiden av hånden, men BI-tingene er litt som en svart boks når det kommer til plattformhelse. Og det er det ikke, de har ikke mye kunnskapsgrunnlag rundt det. Jeg gjør det, bare fra å ha jobbet i det i fem til ti år, ikke sant? Men typiske mennesker som er ansvarlige for å finne disse, eller få varsler og finne ut hva som foregikk, det er litt av en svart boks for dem.
Eric Kavanagh: Ja, det kan jeg tenke meg. Jeg ville være nysgjerrig på å vite det, så du viste på den ene skjermen hvordan du kan se alle spørsmålene som kommer gjennom, hvor lang tid de tok å kjøre, og hvem som genererte dem. Kan du også se den faktiske strukturen til selve SQL-spørringen og gjøre noen analyser rundt det? Som kanskje noen ganger folk setter sammen SQL-spørsmål som er slags klumpete, la oss si og tungvint, i motsetning til en mester som virkelig setter sammen en fin, tett spørring. Er det noe du kan visualisere gjennom dette verktøyet og så hjelpe deg med at det er problemet?
Stan Geiger: Ja, så det du kan gjøre, som det jeg har gjort her, er at jeg nettopp har sortert etter bortfallet tid. Så jeg kan se de som tok lengst og så får jeg teksten, men så er det fremdeles opp til noen som er mer eller mindre fageksperter å se på det og gå, “Å, OK, her er grunnen til at det tok så lang tid . "Det er noe som vi har en slags arbeidsbelastningsanalyse, vi kaller det SQL Workload Analyzer for databasesiden, som jeg har lurt rundt med ideen om å kanskje komme ned på veien med en lignende ting, slik at den identifiserer disse spørsmålene og gir deg anbefalinger om hvordan du kan stille inn spørsmålene. Men ett av problemene er at denne MDX-spørringen er et ganske spesialisert språk.
Eric Kavanagh: Ja, det kan jeg tenke meg. Men du kan for eksempel se hvem personene er, så det er ikke så vanskelig å finne ut om en person, hvis en fyr er ansvarlig for ti av de lengste prosessspørsmålene, så hvis ikke noe annet kan du ringe ham opp, eller ringe manageren hans eller noen og sier: "Hei, denne fyren tygger opp mye båndbredde, " og kanskje viser det seg at det er de mest verdifulle spørsmålene for bedriften, ikke sant? Du må sette det i sammenheng med hva forretningsverdien er, fra spørsmålene i seg selv er det ikke bare et klart tallspill, ikke sant? Det er å finne ut, vel, denne fyren er strømbrukeren vår, og han er den som endrer virksomheten, ikke sant?
Stan Geiger: Nei, du har helt rett. Jeg mener, det er en av måten kundene bruker dette på, er å kunne gjøre det. Som du sa, kan du finne et område, fordi en av tingene jeg snakker om, jeg alltid slagger på Excel, men du kan koble deg til analysetjenester i Excel og kjøre pivottabeller av OLAP, og det genererer egne spørsmål, og sender dem, og noen ganger er de ikke den beste formen, så du kan gå tilbake og identifisere disse og faktisk skrive om dem og gi dem til brukeren og la dem kjøre dem utenfor der, slik at det ikke tar en halv time på dem for å komme tilbake til pivottabellen.
Eric Kavanagh: Akkurat. Og når vi snakker om spørsmål, dekker dere spekteret av spørsmål, så dere nevnte MDX, hva med noen av de andre spørsmålene som et DAX-spørsmål, eller noen av disse andre-?
Stan Geiger: Ja, vi dekker, ja, alle DAX og MDX begge. Så en av tingene jeg ikke nevnte, eller jeg gjorde, kanskje, men vi støtter både tabular og OLAP i Microsoft og DAX å være - jeg tror du og jeg snakket om dette for en stund tilbake - er at vi ser mye mer tabell nå enn vi er OLAP. For det er bare enklere å få frem tabellmodeller og sånt, og slik at du kommer til å se åpenbare DAX-spørsmål, men vi får også tak i disse.
Eric Kavanagh: Ja, det er interessant. Har du noen kontekst rundt hvorfor det skjer? Er det kanskje fordi flere og flere kommer inn på dette, og fordi OLAP selvfølgelig ikke er noe nytt, det har eksistert i hva, minst 30-odde år?
Stan Geiger: Rett, vel, det er en slags kombinasjon, en av tingene er å designe terninger er en kunst. Og kuber ble bygget for å forhåndsaggregere data, så det er veldig raskt å få ut data, men det tar litt tid å bearbeide kuben fordi det må gjøre alle disse sammenstillingene. Og da ble maskinvare billigere og minnet ble billigere, og da kom alle ut med kolonnebutikker og databaser i minnet, egentlig. Og også tabellform er sannsynligvis det nærmeste med tradisjonelle relasjonsdatabaser, og det er bare mye enklere og raskere å få frem tabellmodeller enn det er med OLAP. Men ulempen er at den ligger i minnet, det hele ligger i minnet, så det er veldig minneintensivt og dataene samles ikke før du ber om det. Så, men når det er sagt, begynner vi å se mye mer tabell der ute.
Eric Kavanagh: Det er interessant. Det kan også skyldes at denne bransjen blir litt flatterende ut, og det jeg mener med det, er at vi får mange flere som samhandler med data og bruker forskjellige verktøy, og sikkert når du snakker om Microsoft, tror jeg det er definitivt tilfelle at du har mange, mange flere brukere for små og mellomstore bedrifter, og til og med noen større organisasjoner som graver seg inn i tingene, får tilgang til verktøy, kjører spørsmål, og de er kanskje ikke like kjent med hele prosessen og teknologiene rundt å bygge terninger, til ditt poeng, ikke sant? Fordi det tar noen tanker, og det er også dyrt, ikke sant? Det tar tid, det tar energi å bygge disse kuber med mindre du bruker noen av de nyere teknologiene der ute. Vi har snakket med selskaper som Snowflake, for eksempel, det gjør ganske interessante ting, men jeg tror du har mange flere som bruker tingene, og de kommer sannsynligvis til å følge det du nettopp har beskrevet, som er det tabulære formatet, i motsetning til formelt å bygge kuber, ikke sant?
Stan Geiger: Ja, vel, jeg mener, jeg antar at Excel - når det var, Power Pivot, tror jeg - det er faktisk tabulært, hvis du ser på det; det er slik du bygger tabellmodeller. Og så var neste iterasjon, jeg kan fortelle deg tabellmodellene mine som jeg bygger, og jeg distribuerer den opp til SQL Server slik at jeg kan dele den med alle andre. Så det er en naturlig forlengelse av Excel nesten.
Eric Kavanagh: Ja, det er et godt poeng. Det vi har sett de siste, vil jeg si fem til syv år, er bare en enorm utvidelse av bruken av disse teknologiene, ikke sant? Og Microsoft har ærlig talt vært en pioner i det å virkelig demokratisere strømdataene gjennom analysetjenester og gjennom Power Pivot, ikke sant? Jeg mener, det var en spillskifte for bransjen, ikke sant?
Stan Geiger: Ja, nei, du har helt rett. Jeg mener, jeg har et lysbilde når jeg gir en lengre presentasjon som viser overgangen til å gå fra den semantiske modellen, som var OLAP, til tabellen. Og jeg tror jeg har et sitat fra Microsoft; de vil ha data i hendene på brukerne, ikke bare over veggen i IT-butikken, de ønsker å få mer av dataene i hendene til menneskene som spiser dem.
Eric Kavanagh: Og det kommer tilbake til det første veldig enkle lysbildet som jeg viste, som var den grunnleggende beslutningsprosessen for enhver organisasjon, og nå - og jeg synes dette er en flott ting - får vi flere og flere mennesker fra hele hierarkiet i organisasjonen, og ta hensyn til hva som skjer, bringe historien deres til bordet, og du gjør det med data, det er poenget. Du kan bruke andre måter, men hvis du støtter historien din med data, du kommer til å ha mye sterkere argumenter enn de som ikke gjør det, ikke sant?
Stan Geiger: Akkurat, ja. Som, ja, det er helt riktig. Jeg mener, det var derfor nå, det pleide å være "Hei, jeg trenger denne rapporten, " så nå måtte jeg gå gjennom rapportforespørselen, og jeg måtte gå over her, og få min rapport, og nå kan jeg sitte der rett ved skrivebordet mitt, og egentlig bare, jeg har tilgang til dataene som er generert, tar forretningsavgjørelsene mine.
Eric Kavanagh: Det stemmer. Du kom, jeg kom tilbake fra en konferanse akkurat denne siste uken, og det kom en hysterisk kommentar fra en fyr som driver et ganske stort BI-miljø for butikken Target, og han refererte til selvbetjeningsanalyse og selvbetjenings BI, og tydeligvis det er et stort tema i disse dager. Jeg er sikker på at det er noe som driver mye aktivitet for det dere gjør på IDERA fordi når du vil rulle ut selvbetjening, først og fremst skal du ha et sunt BI-miljø, ikke sant? Hvis du skal få alle slags mennesker der ute som stiller alle slags spørsmål på alle slags måter, vil du ha noe som dette verktøyet her, for å kunne forstå hvem som stiller hvilke spørsmål og hvor. Og det morsomme sitatet jeg vil kaste ut bare for spark her, som du sa, "Det er en fin linje mellom BI med selvbetjening og gå F selv."
Stan Geiger: Ja.
Eric Kavanagh: Jeg trodde det var hysterisk. Men ser du at trenden med selvbetjening virkelig driver mye bevissthet rundt hva du gjør med teknologien?
Stan Geiger: Ja, for som du sa, hvis du skal tillate BI til selvbetjening, så kommer du sannsynligvis til å få noen ytelsesproblemer, på grunn av bare: A) mengden tilgang, hvor mye folk som går på dataene, og B) mengden dårlig dannede spørsmål og måter å få tilgang til den du har. Så, du virkelig, det er veldig viktig at du overvåker miljøet, slik at du kan holde alle glade som prøver å konsumere dataene, ikke sant?
Eric Kavanagh: Ja, jeg tror det er helt riktig. Det er en velsignelse og en forbannelse: det er bra at folk prøver å bruke tingene, men igjen, til ditt poeng, hvis du ikke har det rette verktøyet den gangen, kommer du til å bli en ulykkelig bobil fordi du skal rulle ut selvbetjening uten et verktøy som dette, for meg synes det bare er å be om et fjell av trøbbel.
Stan Geiger: Ja, jeg mener, det ligner på da jeg bygde datavarehus, det er som om du ikke fikk dimensjonene og faktatabellene dine riktig, så du løsnet det for ad hoc-rapportering, kanskje du vil krype under en stein.
Eric Kavanagh: Det er kjempebra. Ja, det er bra, igjen, det er gode nyheter at folk bruker disse tingene, men jeg tror jeg må tro at selvbetjening kommer til å drive mye aktivitet for det du gjør, fordi du snakker om ramping øke mengden spenning og mengden trykk på disse systemene etter størrelsesordrer. Ikke bare etter en eller to størrelsesordrer, og det er det poenget at du virkelig ønsker å ha en viss synlighet og at du vil kunne se hvem som gjør hva, hvor, når, hvordan og hvorfor. Still spørsmålene og ta noen avgjørelser om hvordan du kan overvåke og endre miljøet og endre retningslinjene dine for hvem som får tilgang til hva, ikke sant?
Stan Geiger: Rett. Og du vet, det også, å vite, å se at utnyttelse også lar deg gå inn dit, og potensial, som jeg nevnte objektet i kuben, kan jeg gjøre ting for å forbedre det, at så langt som jeg bygger og designer tingene. Så det er viktig at ikke bare det for å se på tingenes ytelse, men for å kunne se hvordan planen din og designen din presterer på det nivået også, for å kunne lage finpregninger til det. Og det kommer bare til å bli større og større ettersom ting som makt BI er den store greien nå, med Microsoft, så nå kan jeg bygge mine egne dashboards og widgets og ting, og ikke trenger å være BI-utvikler.
Eric Kavanagh: Det stemmer. Ja, det er gode ting, det kommer overalt, men du trenger noen måte å administrere det miljøet på, eller du vil få ulykkelige brukere. Det fører til ulykkelig ledelse, noe som fører til at folk blir sparken. Det er en ganske klar dominoeffekt når ting begynner å falle, men dette er gode ting.
Så jeg tygget opp de siste fem minuttene her. Robin, hadde du noen spørsmål?
Robin Bloor: Jeg synes det er fascinerende å være ærlig. Det har meg til å tenke på det faktum at vi hadde veldig begrensede miljøer og selvbetjening faktisk endrer verden, og mye av det som faktisk skjer virkelig fordi det er kommet veldig mye mer data inn i miljøet enn det som skjedde før. Det eneste spørsmålet, fordi vi ikke har mye tid, men det eneste spørsmålet jeg ville være interessert i å stille det er som om du forklarte måten det - fordi jeg trodde det var en veldig god demo - slik som BI-overvåking fungerer. Jeg lurte på hva gjør folk som ikke har denne typen ting egentlig? Fordi det må være en veldig vanskelig, er det en rekke ting der du gjør en forskjell, rotårsak er vel, du kommer ikke nødvendigvis alltid til grunnårsaken, men du kan komme til rotårsaken med noen av tingene at du ser på, at når du sa at en rekke mennesker kjøper verktøyet bare for å vite hvem som kjører hva, og at tankene mine snurrer, fordi det er som om du ikke vet hvem som kjører hva, så er ting ute av kontroll. Så, hvordan ser miljøet ut når det er utenfor kontroll?
Stan Geiger: Jeg mener, du kan få all denne informasjonen som vi har i verktøyet selv, men du må skrive en haug med hjemmelaget scripting og fordi dataene alle er der ute, det er bare du må vite hvor du skal få det, som krever et kompetanse, ikke sant? Så i miljøer der du ikke har det kompetansenivået, egentlig er det du får, er hei, er det opp eller ned? Jeg vet egentlig ikke om det kjører effektivt eller ikke, men det er oppe, ikke sant? Og så begynner jeg å få telefonsamtaler eller folk går, "Hei, rapporten min er ikke i innboksen min, hva skjer?" Eller "Jeg sendte nettopp denne rapporten gjennom rapporteringstjenester", eller de kan gjøre et spørsmål her i analysetjenester, men det er tatt som en halvtime, og det pleide å ta omtrent 30 sekunder, hva skjer? Nå, nå må du gjøre brannøvelsen og prøve å finne ut av det, og uten verktøy blir det veldig vanskelig.
Robin Bloor: Vel, riktig, det var det som bare ble stadig tydeligere for meg, da du demonstrerte hver av dimensjonene til det du faktisk har fått til her. Den andre tingen, det er som på et veldig, veldig primitivt nivå, hvis du ikke har varsler som forteller deg at ting går galt, så er det bare et dyrt - du kommer i en dyr situasjon og prøver å kurere det som har skjedd, fordi du finner ikke ut av det før ting begynner å falle dårlig, ikke sant?
Stan Geiger: Rett, du vet ikke hva du ikke vet.
Eric Kavanagh: Du har det. Vel, hei folkens, vi har brent gjennom en time og endret oss her. Veldig stor takk til vår egen Robin Bloor, og selvfølgelig vår venn, Stan Geiger, fra IDERA Software. De kommer til å være på Enterprise Data World, faktisk, hvis noen av dere skal ned dit, vil din virkelig være der også i Atlanta. Vår gode venn, Tony Shaw, gjør en god jobb som kjører den konferansen fire år nå, og hei det gamle er nytt igjen. Det hele er varme ting. Forhåpentligvis ser vi deg der ute, hvis ikke, sjekk tilbake med oss neste uke, så har vi en rekke andre web-sendinger stilt opp.
Alltid nysgjerrig på å høre tankene dine, sende en e-post til det som går rett for meg, hvis du har spørsmål eller forslag, eller andre teknologier du vil lære om i Hot Technologies. Og med det skal du ta farvel, folkens. Takk igjen for at du ble med, så snakker vi deg neste gang. Ha det fint. Ha det.
