Af Techopedia Staff, 22. juni 2016
Takeaway: Værten Rebecca Jozwiak diskuterer fordelene ved datakataloger med Dez Blanchfield, Robin Bloor og David Crawford.
Du skal tilmelde dig denne begivenhed for at se videoen. Registrer dig for at se videoen.
Rebecca Jozwiak: Mine damer og herrer, hej og velkommen til Hot Technologies i 2016. I dag har vi ”Kraften i forslaget: Hvordan et datakatalog giver analytikere.” Jeg er din vært Rebecca Jozwiak, der udfylder vores sædvanlige vært Eric Kavanagh i dag, mens han rejser rundt i verden, så tak for at du kom med os. Dette år er varmt, det er ikke bare varmt i Texas, hvor jeg er, men det er varmt overalt. Der er en eksplosion af alle slags nye teknologier, der kommer ud. Vi har IoT, streaming af data, cloud-adoption, Hadoop fortsætter med at modne og blive adoptert. Vi har automatisering, maskinlæring, og alt dette er naturligvis understreget af data. Og virksomheder bliver flere og flere data drevet af dagen. Og selvfølgelig er poenget med det at føre til viden og opdagelse og, ved du, tage bedre beslutninger. Men for virkelig at få mest muligt ud af data, skal det være let at komme til. Hvis du holder det låst væk, eller begravet eller i hjernen hos nogle få mennesker i virksomheden, gør det ikke meget godt for virksomheden som helhed.
Og jeg tænkte lidt på datakatalogisering og tænkte selvfølgelig på biblioteker, hvor det for længe siden var, hvor du tog hen, hvis du havde brug for at finde ud af noget, hvis du havde brug for at undersøge et emne, eller kigge efter nogle oplysninger, gik du til biblioteket, og selvfølgelig gik du til kortkataloget, eller den ude dame, der arbejdede der. Men det var også sjovt at slags vandre rundt, hvis du bare ville kigge efter, og at du måske bare opdager noget pænt, kan du finde ud af nogle interessante fakta, som du ikke vidste, men hvis du virkelig havde brug for at finde ud af noget, og du vidste, hvad du ledte efter, du havde brug for kortkataloget, og selvfølgelig er virksomhedsækvivalenten et datakatalog, der kan hjælpe med at skinne lys over alle data, som vores brugere kan berige, opdage, dele, forbruge og virkelig hjælpe folk kommer til data hurtigere og lettere.
Så i dag har vi Dez Blanchfield, vores egen dataforsker, og vi har doktor Robin Bloor, vores egen chefanalytiker, vi har David Crawford fra Alation, som skal tale om sit virksomheds datakatalogiseringshistorie, men først vi går videre med Dez. Dez, jeg sender bolden til dig, og gulvet er dit.
Dez Blanchfield: Tak, tak for at have mig i dag. Dette er et spørgsmål, jeg er ekstremt interesseret i, for næsten hver organisation, jeg støder på i mit daglige arbejde, finder jeg nøjagtigt det samme emne, som vi talte meget kort om i før-show-skænderiet, og det er det de fleste organisationer, der har været i forretning i mere end et par år, har en overflod af data begravet omkring organisationen, forskellige formater, og faktisk har jeg klienter, der har datasæt, der går tilbage til Lotus Notes, databaser, der stadig kører i nogle sager som deres pseudo-internetter, og de løber alle ind i denne udfordring med faktisk at finde, hvor deres data er, og hvordan man får adgang til dem, hvem der skal give adgang til dem, hvornår man skal give adgang til dem, og hvordan man bare katalog, og hvordan man får det til et sted, hvor alle kan: A) være opmærksomme på hvad der er, hvad der er der, og B), hvordan man får adgang til det og bruger det. Og en af de største udfordringer er naturligvis at finde den, den anden store udfordring er at vide, hvad der er derinde, og hvordan man får adgang til det.
Jeg kan godt vide, at jeg har mange titalls databaser, men jeg ved faktisk ikke, hvad der er derinde, eller hvordan jeg finder ud af, hvad der er der, og så uundgåeligt, som vi opdager nu i dataene før showet, har du en tendens at gå rundt på kontoret og stille spørgsmål og råbe på tværs af de kubiske vægge og prøve at finde ud af, ofte er min oplevelse, at du måske endda finder ud af, at du vandrer til receptionen, receptionen og spørger, om nogen ved, hvem du vil tale med. Ganske ofte er det ikke altid it-folk, fordi de ikke er opmærksomme på datasættet, fordi nogen lige har oprettet det, og det kunne være noget enkelt som et - ganske ofte finder vi et projekt af en eller anden art, der står op i it-miljø og projektlederen har brugt et regneark med alle ting, og det har fået en massiv mængde værdifuld information omkring aktiver og kontekst og navn, og medmindre du kender projektet og kender den person, kan du bare ikke finde disse oplysninger. Det er bare ikke tilgængeligt, og du skal få fat i den originale fil.
Der er en sætning, der er blevet dræbt omkring data, og jeg er ikke nødvendigvis enig i det, men jeg synes, det er en sød lille smid, og det er, at en vis mængde mennesker synes, at data er den nye olie, og jeg sikker på, at vi også vil dække det på et eller andet aspekt, senere i dag. Men hvad jeg har bemærket, og bestemt er en del af denne transformation, er, at organisationer af virksomheder, der har lært at værdsætte deres data, har vundet betydelig fordel i forhold til deres konkurrenter.
Der var et interessant papir fra IBM for omkring fem eller seks år siden, og de undersøgte omkring 4.000 virksomheder her i Australien, og de tog alle oplysninger, alle resultatdata, alle finansdata og satte dem sammen i en kogende gryde og derefter sendte den til Australian School of Economics, og de startede faktisk en fælles tendens her, og det var, at virksomheder, der udnyttede teknologi, altid fik en sådan konkurrencefordel i forhold til deres jævnaldrende og konkurrenter i sig selv, at deres konkurrenter næsten aldrig indhenter, og jeg tror det er meget tilfældet nu med data, som vi har set, hvad folk kalder en digital transformation, hvor organisationer, der klart har fundet ud af, hvordan de finder data, de har, at gøre disse data tilgængelige og gøre dem tilgængelige i nogle meget let forbrugsstoffer mode til organisationen, uden at nødvendigvis altid vide, hvorfor organisationen muligvis har brug for det, og få betydelig fordel i forhold til konkurrenterne.
Jeg har et par eksempler på dette lysbillede, som du kan se. Min ene linje er, er, at den store forstyrrelse i næsten alle brancher efter min mening styres af data, og hvis de nuværende tendenser er noget at gå hen, er min opfattelse, at vi bare virkelig har fået startede, fordi når de mangeårige mærker endelig vågner op til, hvad det betyder og går ind i spillet, vil de deltage i spillet i engroshandel. Når slags af de store detailhandlere, der har bjerge af data, begynder at anvende en historisk analyse af dataene, hvis de endda ved, at de findes, så vil nogle af online-spillerne få lidt af et wakeup call.
Men med mange af de fleste af disse mærker, mener jeg, at vi har Uber, der er det største taxafirma i verden. De ejer ikke nogen taxaer, så hvad er det der gør dem magiske, hvad er deres data? Airbnb, den største udbyder af boliger, vi har WeChat, det største telefonfirma i verden, men de har ingen faktisk infrastruktur og ingen håndsæt, ingen telefonlinjer. Alibaba, den største forhandler på planeten, men de ejer ikke noget af lageret. Facebook, det største mediefirma i ordet. Jeg tror, at de ved det sidste antal havde 1, 4 milliarder aktive databrugere nu, hvilket er et forbløffende nummer. Det er ikke nogen steder i nærheden - jeg tror, at nogen hævdede, at en fjerdedel af planeten faktisk er der hver dag, og alligevel er her en indholdsudbyder, der faktisk ikke opretter indholdet, alle de data, de tjener, er ikke oprettet af dem, det er oprettet af deres abonnenter, og vi kender alle denne model.
SocietyOne, som du måske eller måske ikke har hørt om, det er et lokalt brand, jeg tror, i et par lande er det en bank, der faktisk udgiver peer-to-peer-udlån, så med andre ord har den ingen penge. Det eneste, det gør, er, at det administrerer transaktionerne, og dataene sidder under det. Netflix, vi er alle meget, meget fortrolige med det. Der er en interessant enforing her. Da Netflix lovligt var i stand til at blive brugt i Australien, da det officielt blev annonceret, behøvede du ikke at bruge en VPN for at komme til det, har mange mennesker rundt om i verden en tendens til - hvis du ikke kan komme til det i dit lokale område - Da Netfix blev lanceret i Australien, øgede det den internationale båndbredde på vores internetforbindelser med 40 procent, så det næsten fordoblet internetforbruget i Australien natten over, med kun en applikation, en sky-hostet applikation, der ikke gør andet end at lege med data. Det er bare en forbløffende statistik.
Og selvfølgelig er vi alle bekendt med Apple og Google, men dette er de største softwarevirksomheder på planeten, og alligevel skriver de faktisk ikke apps. Hvad er den konsistente ting med alle disse organisationer? Det er data, og de kom ikke der, fordi de ikke vidste, hvor deres data var, og de vidste ikke, hvordan de skulle katalogisere dem.
Det, vi finder nu, er, at der er denne helt nye aktivklasse, der kaldes data, og virksomheder vågner op til det. Men de har ikke altid værktøjer og knowhow og hvorfor til at kortlægge alle disse data, til at katalogisere alle disse data og gøre dem tilgængelige, men vi har fundet ud af, at virksomheder med næsten ingen fysiske aktiver har opnået høj markedsværdi i registrere tid via denne nye datakapitalklasse. Som jeg sagde, vågner nogle af de gamle spillere nu op til dette og bringer det bestemt ud.
Jeg er en stor fan af at tage folk med på en lille smule rejse, så i de atten hundrede, sent atten hundrede, og du vil være mere end fortrolig med dette på det amerikanske marked, viste det sig, at for at køre en folketælling hvert år, tror jeg, de har kørt dem hvert tiende år på det tidspunkt, men hvis du skal føre en folketælling hvert år, kan det tage op til otte eller ni år at faktisk foretage dataanalysen. Det viste sig, at datasættet derefter gik tilbage i kasser på steder i papir, og næsten ingen kunne finde det. De fortsatte med at pumpe disse rapporter ud, men de faktiske data var meget svære at komme til, vi har en lignende situation med en anden verdensomspændende øjeblik omkring 1940'erne med Anden verdenskrig, og denne ting er Bletchley Park Bombe stavet BOMBE, og det var et massivt analytisk værktøj til sammenknusning af tal, der ville gå gennem små datasæt og finde signaler i det, og bruges til at hjælpe med at knække koder gennem Enigma.
Denne ting igen var i det væsentlige en enhed designet, ikke meget til at katalogisere, men til at tagge og kortlægge data, og gøre det muligt at tage mønstre og finde det inde i datasættet, i dette tilfælde bryde koder, finde nøgler og sætninger og finde dem regelmæssigt i datasættene, og derfor har vi været igennem denne rejse med at finde ting i data og føre til katalogisering af data.
Og så fulgte disse ting sammen, disse massive lavprisen med maskiner, lige uden for hylden. Og vi gjorde nogle meget interessante ting, og en af de ting, vi gjorde med dem, er, at vi byggede meget lave omkostningsklynger, der kunne begynde at indeksere planeten, og meget berømt disse store mærker, der er kommet og gået, men sandsynligvis er Googles det mest almindelige hjem brand, som vi alle har hørt om - det er blevet et faktisk verb, og du ved, at du har succes, når dit brand bliver et verb. Men hvad Google lærte os, uden at indse det, muligvis i erhvervslivet, er, at de var i stand til at indeksere hele planeten til et bestemt niveau og katalogisere de data, der var rundt om i verden, og gøre dem tilgængelige på et meget let, praktisk form i en lille lille formular på én linje, en webside med næsten intet på, og du skriver din forespørgsel, den går og finder den, fordi de allerede havde gennemsøgt planeten, indekseret den og gjort den let tilgængelig.
Og det, vi har bemærket, var: ”Nå, hold på, vi gør ikke det i organisationer - hvorfor er det? Hvorfor er det, at vi har en organisation, der kan kortlægge hele planeten og indeksere den, gennemgå og indeksere den og gøre den tilgængelig, vi kan søge efter den og derefter klikke på den ting, du skal gå og finde den, hvordan kommer vi har ikke gjort det internt? ”Så der er masser af disse små racks af maskiner over hele verden nu, der gør det for intranet og finder ting, men de er stadig virkelig bare ved at gribe tanken om at gå ud over det traditionelle web side eller en filserver.
I stedet for nu at gå ind i denne næste generation af datakatalog på mange måder, er at opdage datatilgang via post-it-notater og vandkøler-samtaler ikke rigtig en passende metode til dataopdagelse og katalogisering længere, og faktisk tror jeg det ikke nogensinde virkelig var det. Vi kan ikke længere føre hele denne udfordring til folk, der bare passerer noter, bogfører noter og chatter om det. Vi er langt fra det område, hvor denne næste generelle tilgang til datakatalogisering er kommet og gået. Vi er nødt til at få vores arme omkring det. Hvis dette var et let problem, ville vi allerede have løst det på mange måder tidligere, men jeg tror, at det ikke er et let problem, bare indeksering og opkald til dataene er kun en del af det, at vide, hvad der findes i dataene og opbygge metadata omkring det, vi opdager, og derefter gøre det tilgængeligt i en let, forbrugsbar form, især til selvbetjening og analyse. Det er stadig et problem at blive løst, men mange dele af puslespillet om fem år er godt og virkelig løst og tilgængeligt.
Som vi ved, er mennesker, der katalogiserer data, en opskrift på fiasko, fordi menneskelig fejl er en af de største mareridt, vi beskæftiger os med i databehandlingen, og jeg taler jævnligt om dette emne, hvor mennesker efter min mening sandsynligvis udfylder papirformularer er det største mareridt vi beskæftiger os med big data og analyse, med konstant at skulle rette tingene, de gør, selv ned til enkle ting som datoer og felter, og folk sætter det i forkert format.
Men som jeg har sagt, vi har set internetsøgemaskiner indeksere verden hver dag, så nu gør vi os til ideen om, at det kan gøres på forretningsdatasæt i opdagelsesprocessen, og værktøjer og systemer er nu let tilgængelig, som du er ved at lære i dag. Så det trick efter min mening er at vælge de rigtige værktøjer, de bedste værktøjer til jobbet. Og mere passende oven på det at finde den rigtige del af det for at hjælpe dig med at komme i gang på denne vej. Og jeg tror, vi kommer til at høre om det i dag, men inden vi gør det, overgår jeg til mit college, Robin Bloor og hører hans holdning til emnet. Robin, kan jeg videregive til dig?
Robin Bloor: Ja, det kan du bestemt. Lad os se om dette fungerer, åh ja det gør det. Okay, jeg kommer fra en anden retning end Dez virkelig, men jeg ender på samme sted. Dette handler om at oprette forbindelse til data, så jeg tænkte bare, at jeg skulle gå gennem virkeligheden ved at oprette forbindelse til data, punkt for punkt virkelig.
Der er en kendsgerning, at data er mere fragmenterede, end de nogensinde har været. Mængden af data vokser fænomenalt, men faktisk vokser de forskellige datakilder også utroligt, og derfor bliver data mere og mere fragmenteret hele tiden. Men på grund af analytiske applikationer især - men det er ikke de eneste applikationer - har vi en rigtig god grund til at oprette forbindelse til alle disse data, så vi sidder fast på et vanskeligt sted, vi sidder fast i en verden af fragmenterede data, og der er mulighed i dataene, som Dez kaldte det, den nye olie.
Om data, vel, det plejede at leve på spinding disk, enten i filsystemer eller databaser. Nu lever det i et meget mere varieret miljø, det lever i filsystemer, men det lever også i Hadoop-tilfælde i dag, eller endda i gnist-tilfælde. Den lever i flere databaser. For ikke så længe siden standardiserede vi en eller anden relationel database, du ved, at der gik ud af vinduet i de sidste fem år, fordi der er et behov for dokumentdatabaser, og der er behov for grafdatabaser, så du ved, at spillet har ændret. Så det levede på spin-disk, men det lever nu på SSD. Den seneste mængde SSD - bestemt den nyeste SSD-enhed kommer ud fra Samsung - tyve gigabyte, hvilket er enormt. Nu lever det i hukommelsen, i den forstand, at den primære kopi af data kan være i hukommelsen snarere end på disk, vi plejede ikke at bygge systemer som det; det gør vi nu. Og det lever i skyen. Hvilket betyder, at det kan leve i en af disse ting, i sky, du behøver ikke nødvendigvis vide, hvor det er i en sky, du vil kun have dens adresse.
Bare for at ramme hjemmet, er Hadoop indtil videre mislykket som et udvideligt datalager. Vi havde håbet, at det ville blive et udvideligt datalager, der skaleres ud, og det ville bare blive et filsystem for alt, og det ville - regnbuer optrådte i himlen, dybest set, og enhjørninger ville danse rundt, og intet af det skete. Hvilket betyder, at vi ender med et problem med datatransport, og der er ikke behov for datatransport til tider, men det er også en vanskelighed. Data har virkelig tyngdekraften i dag, når du først er kommet ind i multi-terabyte med data, samler dem op og kaster dem rundt, forårsager slags forsinkelser på dit netværk eller vises forskellige steder. Hvis du vil transportere data rundt, er timing en faktor. Der er næsten altid, i dag, nogle grænser for, hvor lang tid du har til at få en ting, en data fra et sted til et andet sted. Der plejede at være det, vi plejede at tænke på som batchvinduer, når maskinen var slags inaktiv, og uanset hvor meget data du havde, kunne du bare smide det rundt, og det hele kunne ordne sig. Nå, det er væk, vi lever i en meget mere en realtid verden. Derfor er timing en faktor. Så snart du vil flytte data rundt, så hvis dataene har tyngdekraft, kan du sandsynligvis ikke flytte dem.
Datastyring er en faktor i den forstand, at du faktisk er nødt til at administrere alle disse data, du får ikke dem gratis, og det kan være nødvendigt at replikere for faktisk at få dataene til at udføre det job, de skal gøre, fordi det er måske ikke, hvor du har sagt det. Det har muligvis ikke tilstrækkelige ressourcer til at udføre den normale behandling af dataene. Så data bliver replikeret, og data bliver replikeret mere, end du kunne forestille dig. Jeg tror, at nogen fortalte mig for længe siden, at det gennemsnitlige stykke data gentages mindst to og en halv gang. ESBs eller Kafka præsenterer en mulighed for dataflyt, men i dag kræver det arkitektur. I dag skal du virkelig tænke på en eller anden måde, hvad det faktisk betyder at smide dataene rundt. Derfor er det normalt at foretrække at få adgang til data, hvor det er, så længe du selvfølgelig kan få den ydelse, du har brug for, når du faktisk går efter dataene, og det afhænger af kontekst. Så det er en vanskelig situation alligevel. Med hensyn til dataforespørgsler plejede vi at være i stand til at tænke i form af SQL, vi er virkelig kommet op nu, du ved, forskellige former for forespørgsler, SQL ja, men tilstødende, også grafiske forespørgsler, Spark er kun et eksempel på gør graf, fordi vi også er nødt til at udføre tekstsøgning, mere end vi nogensinde har gjort, også regex-type søgninger, som er virkelig komplicerede søgninger efter mønstre og ægte mønster-matching, alle disse ting bobler faktisk ud. Og alle af dem er nyttige, fordi de får dig det, du leder efter, eller de kan få dig det, du leder efter.
Forespørgsler nu dage spænder over flere data, så det gjorde det ikke altid, og ofte er ydelsen rystende, hvis du gør det. Så det afhænger af omstændighederne, men folk forventer at være i stand til at forespørge data fra flere datakilder, så dataforbindelse af en eller anden slags bliver mere og mere aktuel. Datavirtualisering, som er en anden måde at gøre det på, afhængigt af ydeevnen, er også meget almindeligt. Dataforespørgsler er faktisk en del af en proces, ikke hele processen. Det er bare værd at påpege, at hvis du faktisk ser på analytiske ydelser, kan den faktiske analyse tage meget frygtelig længere tid end dataindsamlingen, fordi det afhænger af omstændighederne, men dataforespørgsler er en absolut nødvendighed, hvis du vil gøre noget slags analyser på flere datakilder, og det bare, du skal faktisk have kapaciteter, der spænder.
Så om kataloger. Kataloger findes af en grund, i det mindste siger vi, at du ved, det er, vi har mapper, og vi har skemaer i databaser, og vi har hvert katalog, og vi har, uanset hvor du går, du vil finde et sted, og så vil du faktisk opdager, at der er en slags katalog, og det samlede globale katalog er en åbenlyst god idé. Men meget få virksomheder har sådan noget. Jeg kan huske, tilbage i året to tusinde - året to tusinde panik - jeg kan huske, at kommunister ikke engang kunne fastlægge hvor mange eksekverbare de havde, ligegyldigt hvor mange forskellige datalagre de havde, og det er sandsynligvis tilfældet nu, ved du, at de fleste virksomheder ikke aktivt ved i global forstand, hvilke data de har. Men det bliver åbenlyst mere og mere nødvendigt at faktisk have et globalt katalog, eller i det mindste have et globalt billede af, hvad der foregår på grund af væksten i datakilder, og den fortsatte vækst af applikationer, og det er især nødvendigt for analyse, fordi du også på en måde, og der er andre problemer her som afstamning og problemer med dataene, og det er nødvendigt for sikkerhed, mange aspekter af datastyringen, hvis du virkelig ikke ved, hvilke data du har, ideen at du vil styre det er bare absurd. Altså, alle data er katalogiseret på en eller anden måde er bare et faktum. Spørgsmålet er, om kataloget er sammenhængende, og hvad du faktisk kan gøre med det. Så jeg vender tilbage til Rebecca.
Rebecca Jozwiak: Okay, tak Robin. Dernæst har vi David Crawford fra Alation, David. Jeg vil gå foran og sende bolden til dig, og du kan tage den væk.
David Crawford: Mange tak. Jeg værdsætter virkelig, at jer, der har mig på dette show. Jeg tror, jeg vil komme i gang med dette, så jeg tror, min rolle her, er at tage noget af den teori og se, hvordan den faktisk anvendes, og de resultater, vi er i stand til at køre hos rigtige kunder, og så kan du se nogle få på diaset, vil jeg tale om, hvilke resultater vi vil være i stand til at se i analytiske muligvis forbedringer. Så for at motivere til diskussionen skal vi tale om, hvordan de kom dertil. Så jeg er heldig, der kommer til at arbejde temmelig tæt med en masse rigtig smarte mennesker, disse kunder, og jeg vil bare påpege et par, der har været i stand til rent faktisk at måle, og tale om, hvordan det at have et datakatalog har påvirket deres analytiker workflow. Og bare for kortvarigt at være foran, tror jeg, en af de ting, som vi ser ændre sig, med datakataloger vers tidligere medierede løsninger og en af måderne, hvorpå relationer virkelig tænker over de løsninger, vi sætter sammen, er at starte fra analytikerne og arbejde baglæns. For at sige, lad os gøre dette med at aktivere analytikernes produktivitet. I modsætning til bare overholdelse, eller i modsætning til bare at have en opgørelse, laver vi et værktøj, der gør analytikere mere produktive.
Så når jeg taler med en dataforsker på det finansielle serviceselskab Square, er der en fyr, Nick, der fortalte os om, hvordan hans, han plejede at tage flere timer på at finde det rigtige datasæt til at starte en rapport, nu kan han gør det i løbet af sekunder ved hjælp af søgning efter markedsandel, vi talte med deres CTO, der trak hans analytikere, der brugte Square, undskyld mig, brugte Alation, for at finde ud af, hvad deres, hvilke fordele de så, og de rapporterede en 50 procent produktivitetsstigning, og at den, en af verdens største forhandlere, eBay, har over tusind mennesker, der udfører SQL-analyse regelmæssigt, og jeg arbejder temmelig tæt med Deb Says derovre, hvem er projektet manager i deres data-værktøjsteam, og hun fandt ud af, at når forespørgsler vedtager Alation, vedtager et katalog, ser de dobbelt så høj hastighed, som de skriver nye forespørgsler mod databasen.
Så dette er virkelige resultater, dette er mennesker, der faktisk anvender kataloget i deres organisation, og jeg vil gerne lede dig igennem, hvad det kræver at få opsat. Hvordan et katalog etableres i en virksomhed, og måske det vigtigste at sige, er, at meget af det sker automatisk, så Dez talte om systemer, lærte om systemer, og det er præcis, hvad et moderne datakatalog gør. Så de installerer Alation i deres datacenter og derefter forbinder de det til forskellige kilder til metadata i deres datamiljø. Jeg vil fokusere lidt på databaserne og BI-værktøjerne - fra begge disse vil vi udtrække tekniske metadata, om dybest set hvad der findes. Rigtigt, så hvilke borde? Hvilke rapporter? Hvad er rapportdefinitionerne? Så de udtrækker de tekniske metadata, og en katalogside oprettes automatisk for hvert objekt inde i disse systemer, og derefter pakker de også ud og lag oven på de tekniske metadata, de lagger ovenpå brugsdataene. Det gøres primært ved at læse forespørgselslogger fra databasen, og dette er en virkelig interessant kilde til information. Så når en analytiker skriver en forespørgsel, når et rapporteringsværktøj, uanset om det er hjemmevokset eller fra hylden, om et rapporteringsværktøj kører en forespørgsel for at opdatere instrumentbrættet, når en applikation kører en forespørgsel for at indsætte data, der skal fungere på et datasæt - alle disse ting er fanget i databaseforespørgselslogfiler. Uanset om du har et katalog eller ej, optages de i forespørgselsloggen med databasen. Hvad et datakatalog kan gøre, og især hvad Alations katalog kan gøre, er at læse disse logfiler, stille spørgsmålene inde i dem og oprette en virkelig interessant brugsgraf baseret på disse logfiler, og vi bringer det i spil for at informere fremtidige brugere af dataene om, hvordan tidligere brugere af dataene har brugt dem.
Så vi bringer al den viden sammen i et katalog, og bare for at gøre dette reelt, det er disse integrationer, der allerede er implementeret hos kunder, så vi har set Oracle, Teradata, Redshift, Vertica og en masse andre relationelle databaser. I Hadoop-verdenen er der en række SQL på Hadoop, en slags relationelle, meta-butikker oven på Hadoop-filsystemet, Impala, Tez, Presto og Hive, vi har også set succes med sky Hadoop private udbydere som Altiscale, og vi har også været i stand til at oprette forbindelse til Tableau-servere, MicroStrategy-servere og indeksere dashboards der, såvel som integrationer med data science kartlægningsværktøjer som Plotly.
Så vi opretter forbindelse til alle disse systemer, vi har tilsluttet disse systemer til kunder, vi har trukket de tekniske metadata ind, vi har trukket brugsdata ind, og vi sorterer automatisk automatisk datakataloget, men på den måde centraliserer viden, men bare centraliserer ting i et datakatalog, giver ikke i sig selv de virkelig vidunderlige produktivitetsforøgelser, som vi talte om med eBay, Square og markedsandel. For at gøre det, er vi faktisk nødt til at ændre den måde, vi tænker på at levere viden til analytikere. Et af de spørgsmål, de stiller for at forberede sig på dette, var "Hvordan påvirker kataloget faktisk en analytikers arbejdsgang?"
Det er hvad vi bruger hele dagen på at tænke på, og for at tale om denne ændring i tankegangen, om et push verses en pull-model, ville jeg gøre en hurtig analogi til, hvordan verden var før og efter at have læst på en Kindle. Så det er bare en oplevelse, som nogle af jer måske har, når du læser en fysisk bog, du støder på et ord, du er ikke sikker på, at du kender ordets definition super godt, du kan måske gætte den ud fra sammenhæng, ikke så sandsynligt, at du vil rejse sig fra sofaen, gå til din boghylde, finde din ordbog, støve den af og vende til det rigtige sted i den alfabetiske liste over ord for at sikre dig, at ja, du havde den definition lige rigtigt, og du ved nyanserne i det. Så det sker ikke rigtig. Så du køber en Kindle-app, og du begynder at læse bøger der, og du ser et ord, du ikke er helt sikker på, og du rører ved ordet. Helt pludselig lige på den samme skærm er ordbordsdefinitionen af ordet med alle dets nuancer, forskellige eksempler på brug, og du stryger lidt, og du får en Wikipedia-artikel om det emne, du stryger igen, får du et oversættelsesværktøj, der kan oversætte det til andre sprog eller fra andre sprog, og pludselig er din viden om sproget så meget rigere, og det sker bare et forbløffende antal gange, sammenlignet med når du skulle gå og træk denne ressource for dig selv.
Og hvad jeg vil argumentere for, er, at arbejdsgangen for en analytiker og den måde, en analytiker vil håndtere datadokumentation, faktisk meget ligner, hvordan en læser vil interagere med ordbogen, hvad enten det er en fysisk, eller om Kindle, og så hvad vi, som vi virkelig så dette produktivitetsforøgelse, spilder ikke kataloget, men forbinder det til arbejdsgangen fra analytikeren, og så har de bedt mig om at lave en demo her, og jeg vil at gøre det i fokus for denne præsentation. Men jeg vil bare konfigurere konteksten til demoen. Når vi overvejer at skubbe dataviden til brugerne, når de har brug for det, tror vi, at det rigtige sted at gøre det, stedet hvor de tilbringer deres tid, og hvor de laver analysen, er et SQL-forespørgselsværktøj. Et sted, hvor du skriver og kører SQL-forespørgsler. Og så byggede vi et, og vi byggede det, og det, der virkelig adskiller sig fra det fra andre forespørgselsværktøjer, er dens dybe integration med datakataloget.
Så vores forespørgselsværktøj kaldes Alation Compose. Det er et webbaseret forespørgselsværktøj, og jeg vil vise det til dig om et øjeblik. Et webbaseret forespørgselsværktøj, der fungerer på tværs af alle disse databaselogoer, som du så på det forrige dias. Det, jeg især prøver på at demonstrere, er den måde, kataloginformationen kommer til brugere. Og det gør det på denne slags tre forskellige måder. Det gør det gennem indgreb, og det er her en person, der er en datadministrator, eller en datatillægter, eller en slags administrator på en eller anden måde eller en manager, kan sige, ”Jeg vil sortere en afbrydelse med en note eller en advarsel i arbejdsprocessen, og sørg for, at den leveres til brugerne på det rigtige tidspunkt. ”Så det er en intervention, og vi viser det.
Smarte forslag er en måde, hvor værktøjet bruger al sin samlede viden om kataloget til at foreslå objekter og dele af en forespørgsel, mens du skriver det. Den vigtigste ting at vide der er, at det virkelig drager fordel af forespørgselsloggen for at gøre det, at foreslå ting, der er baseret på brug, og også for at finde endda dele af forespørgsler, der er skrevet før. Og vi viser det.
Og derefter forhåndsvisninger. Når du skriver navnet på et objekt, viser vi dig alt, hvad kataloget ved, eller i det mindste de mest relevante ting, som kataloget ved om det objekt. Så eksempler på dataene, der havde brugt det før, det logiske navn og beskrivelse af dette objekt, kommer alle op til dig, mens du skriver det uden at skulle gå og bede om det.
Så uden at tale mere, kommer jeg til demoen, og jeg venter bare på, at den vises. Hvad jeg vil vise dig her er forespørgselsværktøjet. Det er en dedikeret SQL-skrivegrænseflade. Det er en separat grænseflade fra kataloget i en vis forstand. Dez og Robin talte om kataloget, og jeg hopper lidt over kataloggrænsefladen direkte til, hvordan det bringes direkte ind for at betjene arbejdsgangen.
Jeg viser lige her et sted, hvor jeg kan skrive SQL, og i bunden ser du, at vi slags har nogle oplysninger, der vises om de objekter, som vi refererer til. Så jeg vil bare begynde at skrive en forespørgsel, og jeg stopper, når jeg kommer til et af disse indgreb. Så jeg skriver "vælg", og jeg vil have året. Jeg vil have navnet. Og jeg vil slå nogle lønndata op. Så dette er et uddannelsesdatasæt. Det har oplysninger om videregående uddannelsesinstitutioner, og jeg ser på den gennemsnitlige fakultetsløn, der findes i en af disse tabeller.
Så jeg har faktisk skrevet ordet "løn." Det er ikke nøjagtigt i kolonnen navn på den måde. Vi bruger både de logiske metadata og de fysiske metadata til at stille forslag. Og hvad jeg vil påpege her, er denne gule boks, der vises her. Der står en advarsel i denne søjle. Jeg kiggede ikke efter det, jeg tog ikke en klasse i, hvordan man bruger disse data korrekt. Det kom til mig, og det sker som en advarsel om en fortrolighedsaftale, der har at gøre med disse data. Så der er nogle regler for oplysning. Hvis jeg vil forespørge disse data, vil jeg fjerne data fra denne tabel, skal jeg være forsigtig med, hvordan jeg afslører dem. Så du har en regeringspolitik her. Der er nogle overholdelsesudfordringer, der gør det så meget lettere at overholde denne politik, når jeg ved om det på det tidspunkt, at jeg ser på dataene.
Så jeg har fået det op til mig, og så skal jeg også se på undervisning. Og her ser vi, at forhåndsvisningerne kommer i spil. På denne undervisningssøjle ser jeg - der er en undervisningssøjle på institutionstabellen, og jeg ser en profil af det. Alation går og trækker eksempeldata fra tabellerne, og i dette tilfælde viser det mig noget, der er ret interessant. Det viser mig fordelingen af værdierne, og det viser mig, at nulværdien dukkede op 45 gange i prøven og mere end nogen anden værdi. Så jeg har en fornemmelse af, at vi muligvis mangler nogle data.
Hvis jeg er en avanceret analytiker, kan dette muligvis allerede være en del af min arbejdsgang. Især hvis jeg er en særlig omhyggelig, hvor jeg ville stille en masse profileringsforespørgsler på forhånd. Hver gang jeg nærmer mig et nyt stykke data, tænker jeg altid på, hvad vores datadækning er. Men hvis jeg er ny med dataanalyse, hvis jeg er ny med dette datasæt, antager jeg måske, at hvis der er en kolonne, er den udfyldt hele tiden. Eller jeg kan antage, at hvis det ikke er udfyldt, er det ikke nul, det er null eller noget i den retning. Men i dette tilfælde har vi en masse nuller, og hvis jeg gjorde et gennemsnit, ville de sandsynligvis være forkert, hvis jeg bare antog, at disse nuller faktisk var nul i stedet for manglende data.
Men Alation, ved at bringe denne forhåndsvisning til din arbejdsgang, beder dig slags om at se på disse oplysninger og giver endda slags nybegynderanalytikere en chance for at se, at der er noget at bemærke her om disse data. Så vi har den forhåndsvisning.
Den næste ting, jeg skal gøre, er, at jeg vil prøve at finde ud af, hvilke tabeller man kan få disse oplysninger fra. Så her ser vi de smarte forslag. Det har kørt hele tiden, men især her har jeg ikke engang skrevet noget, men det vil antyde, hvilke tabeller jeg måske vil bruge til denne forespørgsel. Og den vigtigste ting at vide om dette er, at det drager fordel af brugsstatistikkerne. Så i et miljø som f.eks. EBay, hvor du har hundreder af tusinder af borde i en enkelt database, har et værktøj, der slags kan ramme hveden fra skiven og bruge disse brugsstatistikker, er virkelig vigtigt for at lave disse forslag, der er noget værd.
Så det vil foreslå denne tabel. Når jeg ser på forhåndsvisningen, fremhæver vi faktisk tre af de kolonner, som jeg allerede har nævnt i min forespørgsel. Så jeg ved, at den har tre, men den har ikke navnet. Jeg bliver nødt til at få navnet, så jeg vil være med. Når jeg deltager, har jeg nu disse forhåndsvisninger til at finde, hvor er tabellen med navnet. Så jeg ser, at denne har et pænt formateret, slags korrekt aktiveret navn. Det ser ud til at have en række med et navn til hver institution, så det kommer jeg til at gribe ind, og nu har jeg brug for en sammenhængende betingelse.
Og så, hvad Alation gør her, er igen at se tilbage på forespørgselsloggerne, se tidligere gange, at disse to tabeller er blevet samlet, og foreslå forskellige måder at slutte sig til dem. Endnu en gang er der noget indblanding. Hvis jeg ser på en af disse, har den en advarsel, der viser mig, at dette kun skal bruges til samlet analyse. Det vil sandsynligvis producere den forkerte ting, hvis du prøver at gøre noget gennem institutionen efter institution. Mens denne, med OPE-id, godkendes som den rigtige måde at slutte sig til disse to tabeller på, hvis du vil have data på universitetsniveau. Så det gør jeg, og det er en kort forespørgsel, men jeg har skrevet min forespørgsel uden egentlig nødvendigvis at have nogen indsigt i, hvad dataene er. Jeg har faktisk aldrig set et ER-diagram over dette datasæt, men jeg ved allerede meget om disse data, fordi de relevante oplysninger kommer til mig.
Så det er slags de tre måder, som et katalog via et integreret forespørgselsværktøj kan påvirke arbejdsgangen direkte, mens du skriver forespørgsler. Men en af de andre fordele ved at have et forespørgselsværktøj integreret med et katalog er, at når jeg er færdig med min forespørgsel og gemmer den, kan jeg sætte en titel som "Institutionstimer og fakultetslønning", og så har jeg en knap her, der tillader mig at bare offentliggøre det i kataloget. Det bliver meget let for mig at fodre dette tilbage. Selv hvis jeg ikke offentliggør den, bliver den fanget som en del af forespørgselsloggen, men når jeg offentliggør den, bliver det faktisk en del af den måde, det centraliserede sted, hvor al dataviden lever, bor.
Så hvis jeg klikker på Søg efter alle forespørgsler i Alation, vil jeg blive taget - og her ser du noget mere af kataloggrænsefladen - jeg går til en dedikeret forespørgselssøgning, der viser mig en måde at finde spørgsmål på tværs af hele organisationen. Og du ser, at min nyligt udgivne forespørgsel er øverst. Og nogle vil måske bemærke her på, når vi fanger forespørgsler, fanger vi også forfatterne, og vi opretter slags dette forhold mellem mig som forfatter og disse dataobjekter, som jeg nu ved noget om. Og jeg bliver etableret som ekspert på denne forespørgsel og på disse dataobjekter. Det er virkelig nyttigt, når folk har brug for at lære noget om data, så kan de finde den rigtige person til at lære om. Og hvis jeg faktisk er ny på data, uanset om jeg er en avanceret analytiker - som en avanceret analytiker, kan jeg måske se på dette og se en masse eksempler, der ville få mig i gang med et nyt datasæt. Som nogen, der måske ikke føler sig superkyndige med SQL, kan jeg finde foruddannede forespørgsler, der er rapporter, som jeg kan drage fordel af.
Her er en af Phil Mazanett om median SAT-scoringer. Klik på dette, så får jeg en slags katalogside til selve forespørgslen. Den taler om en artikel, der blev skrevet, der refererer til denne forespørgsel, så der er noget dokumentation for mig at læse, hvis jeg vil lære at bruge det. Og jeg kan åbne det i forespørgselsværktøjet ved at klikke på knappen Skriv, og jeg kan bare køre det selv her uden selv at redigere det. Og faktisk får du se en lille smule af vores lette rapporteringsfunktioner, hvor du, når du skriver en forespørgsel, kan indtaste en skabelonvariabel som denne, og det skaber en enkel måde at oprette en form til at udføre en forespørgsel baseret på på et par parametre.
Så det er hvad jeg har til demoen. Jeg vil skifte tilbage til lysbillederne. Bare for en slags sammenfattning viste vi, hvordan en administrator, en datadministrator, kan gribe ind ved at placere advarsler på objekter, der vises i forespørgselsværktøjet, hvordan Alation bruger sin viden om brugen af dataobjekter til at udføre smarte forslag, hvordan det bringer i profilering og andre tip til at forbedre analytikernes arbejdsgange, når de rører ved bestemte objekter, og hvordan al den slags feeds tilbage i kataloget, når der skrives nye spørgsmål.
Det er klart, at jeg er en talsmand på firmaets vegne. Jeg vil sige dejlige ting om datakataloger. Hvis du vil høre direkte fra en af vores kunder, driver Kristie Allen på Safeway et team af analytikere og har en virkelig cool historie om et tidspunkt, hvor hun havde brug for virkelig at slå uret for at levere et markedsføringseksperiment, og hvordan hendes hele hold brugte Alation til at samarbejde og vende virkelig hurtigt om det projekt. Så du kan følge dette bit.ly-link for at tjekke den historie, eller hvis du vil høre lidt om, hvordan Alation kunne bringe et datakatalog ind i din organisation, er vi glade for at oprette en personlig demo. Mange tak.
Rebecca Jozwiak: Tak så meget, David. Jeg er sikker på, at Dez og Robin har et par spørgsmål, inden jeg vender mig til publikumets spørgsmål og svar. Dez, vil du gå først?
Dez Blanchfield: Absolut. Jeg elsker ideen om dette koncept med offentliggjorte forespørgsler og knytter det tilbage til forfatterkilden. Jeg har været mangeårig mester for denne idé om en intern app-butik, og jeg synes, dette er et rigtig godt fundament at bygge videre på.
Jeg kom til at få en vis indsigt i nogle af de organisationer, som du ser at gøre dette, og nogle af de succeshistorier, som de måske havde haft med hele denne rejse om ikke kun at udnytte dit værktøj og platform til at opdage dataene, men transformere også deres interne kulturelle og adfærdsmæssige træk rundt. Nu med denne slags in-house app-butik, hvor du lige bare downloader, konceptet, hvor de ikke kun bare kan finde det, men de kan faktisk begynde at udvikle små samfund med bevarere af den viden.
David Crawford: Ja, jeg tror, vi er blevet overrasket. Vi tror på værdien af at dele forespørgsler, både fra min fortid som produktchef i Adtech og fra alle de kunder, vi har talt med, men jeg er stadig overrasket over, hvor ofte det er en af de allerførste ting, som kunderne tale om som den værdi, de får ud af Alation.
Jeg lavede nogle brugertest af forespørgselsværktøjet hos en af vores kunder, der hedder Invoice2go, og de havde en produktadministrator, der var relativt ny, og de sagde - han fortalte mig faktisk, uopfordret under brugertesten, ”Jeg ville faktisk ikke skrive overhovedet SQL med undtagelse af, at det er gjort let af Alation. ”Og selvfølgelig, som premierminister, går jeg slags:“ Hvad mener du, hvordan gjorde vi det? ”Og han sagde, “ Nå, det er virkelig bare fordi jeg kan logge ind, og jeg kan se alle disse eksisterende forespørgsler. ”At starte med en tom skifer med SQL er en utrolig hård ting at gøre, men at ændre en eksisterende forespørgsel, hvor du kan se det resultat, der er sat ud, og du kan sige, "Åh, jeg har bare brug for denne ekstra kolonne, " eller "Jeg er nødt til at filtrere den til et bestemt datointerval, " det er en meget lettere ting at gøre.
Vi har set slags disse hjælperoller, som produktledere, måske folk i salgsopsioner, der begynder at hente, og som altid har ønsket at lære SQL og begynde at samle det op ved hjælp af dette katalog. Vi har også set, at mange virksomheder har forsøgt at udføre slags open source. Jeg har forsøgt at opbygge denne slags ting internt, hvor de sporer spørgsmålene og gør dem tilgængelige, og der er nogle virkelig vanskelige designudfordringer til at gøre dem nyttige. Facebook har haft et internt værktøj, som de kaldte HiPal, den slags fangede alle forespørgsler skrevet på Hive, men hvad du finder ud af er, at hvis du ikke formår at skubbe brugerne på den rigtige måde, så ender du bare med en meget lang liste med udvalgte udsagn. Og som en bruger, der prøver at finde ud af, om en forespørgsel er nyttig for mig, eller hvis den er god, hvis jeg bare går igennem en lang liste med udvalgte udsagn, vil det tage mig meget længere tid at få noget ude af værdi der end starter fra bunden. Vi tænkte temmelig nøje over, hvordan man laver et forespørgselskatalog, der bringer de rigtige ting foran og giver det på en nyttig måde.
Dez Blanchfield: Jeg tror, at vi alle gennemgår denne rejse fra en meget ung alder, til voksen alder, på mange måder. En flok teknologier. Jeg personligt har jeg gennemgået den samme ægte ting, som at lære at skære kode. Jeg gik gennem magasiner og derefter bøger, og jeg studerede til et vist niveau, og så var jeg nødt til at gå og faktisk få mere træning og uddannelse på det.
Men uforvarende opdagede jeg, at selv når jeg gik fra at undervise mig selv og læse magasiner og læse bøger og hugge andres programmer og gå på kurser på det, endte jeg stadig med at lære så meget af at lave kurserne, som jeg bare talte med andre mennesker, der havde nogle oplevelser. Og jeg synes, det er en interessant opdagelse, at nu, når du bringer det til dataanalyse, vi dybest set ser den samme parallel, at mennesker uvægerligt er ganske smarte.
Den anden ting, jeg virkelig er interesseret i at forstå, er, på et meget højt niveau, mange organisationer vil spørge: ”Hvor lang tid tager det at komme til det punkt?” Hvad er tiptidsrammen, når folk kommer din platform installeret, og de begyndte at finde ud af, hvilke typer værktøjer? Hvor hurtigt er folk bare at se denne ting blive til et virkelig øjeblikkeligt "a-ha" øjeblik, hvor de er klar over, at de ikke engang bekymrer sig om ROI, fordi det er der, men nu ændrer de faktisk den måde, de gør forretning på ? Og de har opdaget en mistet kunst, og de forventer, at de kan gøre noget virkelig, virkelig sjovt med det.
David Crawford: Ja, jeg kan røre ved det lidt. Jeg tror, at når vi bliver installeret, at en af de gode ting, en af de ting, som folk kan lide ved et katalog, der er direkte forbundet til datasystemerne, er, at du ikke starter tomt, hvor du skal udfylde det side for side. Og det er slags sandt for tidligere dataløsninger, hvor du ville starte med et tomt værktøj, og du skal begynde at oprette en side til alt, hvad du vil dokumentere.
Da vi automatisk dokumenterer så mange ting ved at udtrække metadata, i det væsentlige inden for et par dage efter, at softwaren er installeret, kan du få et billede af dit datamiljø, der er mindst 80 procent der i værktøjet. Og så tror jeg, så snart folk begynder at skrive forespørgsler med værktøjet, gemmes de automatisk tilbage i kataloget, og så vil de også begynde at dukke op.
Jeg vil ikke være for ivrig efter at angive det. Jeg synes, to uger er et ret godt konservativt skøn til en måned. To uger til en måned, konservativt skøn over virkelig at vende rundt og føle, at du får værdi ud af det, som om du begynder at dele noget viden og være i stand til at gå der og finde ud af ting om dine data.
Dez Blanchfield: Det er virkelig forbløffende, når du tænker over det. Det faktum, at nogle af de store dataplatformer, som du effektivt indekserer og katalogiserer, vil nogle gange tage op til året at implementere og implementere og stå op ordentligt.
Det sidste spørgsmål, jeg har til dig, før jeg afleverer Robin Bloor, er stik. En af de ting, der straks springer ud mod mig, er, at du tydeligvis har fået hele den udfordring sorteret. Så der er et par spørgsmål bare virkelig hurtigt. Et, hvor hurtigt implementeres stik? Det er klart, at du starter med den største platform, som Oracle og Teradatas osv. Og DB2'er. Men hvor regelmæssigt ser du nye stik komme igennem, og hvilken behandlingstid tager de? Jeg kan forestille mig, at du har en standardramme for dem. Og hvor dybt går du ind i dem? For eksempel verdens verdens Oracle og IBM og endda Tereadata, og derefter nogle af de mere populære af sene open source-platforme. Arbejder de direkte med dig? Opdager I det selv? Skal du have indvendig viden på disse platforme?
Hvordan ser det ud til at udvikle et stik, og hvor dybt involverer du sig disse partnerskaber for at sikre, at disse stik opdager alt, hvad du muligvis kan?
David Crawford: Ja, det er et godt spørgsmål. Jeg tror, at vi for det meste kan udvikle konnektorerne. Det gjorde vi bestemt, da vi var en yngre start og havde ingen kunder. Vi kan helt sikkert udvikle forbindelserne uden brug af intern adgang. Vi får aldrig nogen særlig adgang til de datasystemer, der ikke er offentligt tilgængelige, og ofte uden at vi behøver nogen indvendig information. Vi drager fordel af metadatatjenester, der er tilgængelige af datasystemerne selv. Ofte kan de være temmelig komplekse og svære at arbejde med. Jeg kender især SQL Server, den måde, de administrerer forespørgselsloggen, der er flere forskellige konfigurationer, og det er noget, du virkelig skal arbejde på. Du er nødt til at forstå nuancerne og drejeknapper og ringer på det for at indstille det ordentligt, og det er noget, vi arbejder med kunderne på, da vi har gjort det flere gange før.
Men til en vis grad er det slags offentlige API'er, der er tilgængelige eller offentlige grænseflader, der er tilgængelige, som vi udnytter. Vi har partnerskaber med flere af disse virksomheder, det er for det meste en grund til certificering, så de føler sig godt tilpas med at sige, at vi arbejder, og også at de kan give os ressourcer til testning, undertiden tidlig adgang, måske til en platform, der kommer ud for at sikre, at vi arbejder med de nye versioner.
For at vende en ny forbindelse, vil jeg sige igen, forsøger at være konservativ, lad os sige seks uger til to måneder. Det afhænger af, hvor ens det er. Så nogle af Postgre-værkerne ser meget ud som Redshift. Redshift og Vertica deler en masse af deres detaljer. Så vi kan drage fordel af disse ting. Men ja, seks uger til to måneder ville være fair.
Vi har også API'er, så det - vi tænker også på Alation som en metadata-platform, så hvis der ikke er noget, der er tilgængeligt for os at nå ud og automatisk gribe, er der måder, du kan skrive stikket selv på og skubbe det ind i vores system, så at alt stadig bliver centraliseret i en enkelt søgemaskine.
Dez Blanchfield: Fantastisk. Jeg sætter pris på, at. Så vi overleverer det til Robin, fordi jeg er sikker på, at han også har en overflod af spørgsmål. Robin?
Rebecca Jozwiak: Robin kan være på stum.
Dez Blanchfield: Du har slået dig i stå.
Robin Bloor: Ja, ikke. Beklager, jeg dæmpede mig selv. Hvad er processen, når du implementerer dette? Jeg er slags nysgerrig, fordi der kan være en masse data mange steder. Så hvordan fungerer det?
David Crawford: Ja, sikker. Vi går ind, først er det en slags IT-proces, hvor vi sørger for, at vores server leveres, og sørger for, at netværksforbindelser er tilgængelige, at porte er åbne, så vi faktisk kan få adgang til systemerne. De ved ofte, hvilke systemer de vil starte med. At kende inde i et datasystem, som - og sommetider faktisk hjælper dem. Vi hjælper dem med at tage et første kig på deres forespørgselslog for at forstå, hvem der bruger hvad og hvor mange brugere de har på et system. Så vi hjælper med at finde ud af hvor - de ofte, hvis de har hundreder eller tusinder af mennesker, der muligvis logger på databaser, ved de faktisk ikke, hvor de logger ind, så vi kan finde ud af det forespørgselslogfiler, hvor mange unikke brugerkonti du faktisk logger på og udfører forespørgsler her om en måned eller deromkring.
Så vi kan drage fordel af det, men ofte kun på de vigtigste. Vi får dem oprettet, og så er der en proces med at sige: "Lad os prioritere." Der er en række aktiviteter, der kan ske parallelt. Jeg vil fokusere på træningen til brug af forespørgselsværktøjet. Når folk først begynder at bruge forespørgselsværktøjet, er det for det første mange der elsker det faktum, at det kun er en enkelt grænseflade til alle deres forskellige systemer. De elsker også, at det er webbaseret, ikke involverer nogen installationer, hvis de ikke vil. Fra et sikkerhedsmæssigt synspunkt kan de lide at have en slags indgangspunkt fra et netværksmæssigt synspunkt mellem et slags corp IT-netværk og det datacenter, hvor produktionsdatakilderne bor. Og så konfigurerer de Alation som et forespørgselsværktøj og begynder at bruge Compose som et adgangspunkt for alle disse systemer.
Så når det sker, hvad vi fokuserer på der på træning, er det at forstå, hvad der er nogle af forskellene mellem et webbaseret eller et serverbaseret forespørgselsværktøj versus et, du ville have på dit skrivebord, og nogle af de nuancer, du bruger at. Og på samme tid, hvad vi vil forsøge at gøre, er at identificere de mest værdifulde data, igen drage fordel af forespørgselslogoplysningerne og sige: ”Hej, måske vil du gå ind og hjælpe folk med at forstå disse. Lad os begynde at offentliggøre repræsentative forespørgsler på disse tabeller. ”Det er undertiden den mest effektive måde at meget hurtigt få folk spundet op. Lad os se på din egen forespørgselshistorie, offentliggøre disse ting, så de vises som de første forespørgsler. Når folk ser på en tabellside, kan de se alle forespørgsler, der berørte tabellen, og de kan starte derfra. Og lad os derefter begynde at tilføje titler og beskrivelser til disse objekter, så de er lettere at finde og søge, så du kender nogle af nuancerne i, hvordan du bruger dem.
Vi sørger for, at vi får et grundigt kig på forespørgselsloggen, så vi kan generere afstamning. En af de ting, vi gør, er at vi kigger gennem forespørgselsloggen på tidspunkter, hvor data flyttes fra en tabel til en anden, og det giver os mulighed for at placere et af de hyppigst stillede spørgsmål om en datatabel, hvor kom dette fra? Hvordan stoler jeg på det? Og hvad vi kan vise, er ikke kun, hvilke andre tabeller det kom fra, men hvordan det blev transformeret undervejs. Igen er dette slags drevet af forespørgselsloggen.
Så vi sørger for, at disse ting er konfigureret, og at vi får afstamning ind i systemet, og vi målretter mod de mest værdifulde og de mest gearede stykker metadata, som vi kan etablere på bordsiderne, så når du søger, finder du noget nyttigt.
Robin Bloor: Okay. Det andet spørgsmål - der er mange spørgsmål fra publikum, så jeg vil ikke tage for meget af tiden her - det andet spørgsmål, som den slags kommer til at tænke på er bare smertepunkterne. Der er købt en masse software, fordi folk på en eller anden måde har vanskeligheder med noget. Så hvad er det almindelige smertepunkt, der fører folk til Alation?
David Crawford: Ja. Jeg tror, der er nogle få, men jeg tror, at en af dem, vi hører temmelig ofte, er analytiker ombord. ”Jeg bliver nødt til at ansætte 10, 20, 30 personer på kort sigt, der bliver nødt til at producere ny indsigt fra disse data, hvordan skal de komme op i hastighed?” Så analytiker ombord er noget, vi helt sikkert tackle. Der er også bare at aflaste de senioranalytikere fra at bruge al deres tid på at besvare spørgsmål fra andre mennesker om data. Det er også meget hyppigt. Og begge disse er i det væsentlige uddannelsesproblemer.
Og så vil jeg sige et andet sted, at vi ser, at folk vedtager Alation, er, når de ønsker at oprette et helt nyt datamiljø for nogen at arbejde i. De vil annoncere og markedsføre dette internt for folk at drage fordel af. Så at gøre Alation til frontend for det nye analytiske miljø er meget tiltalende. Det har dokumentationen, det har et enkelt punkt med introduktion til - et enkelt adgangspunkt til systemerne, og så det er et andet sted, hvor folk vil komme til os.
Robin Bloor: Okay, jeg giver dig videre til Rebecca, fordi publikum prøver at komme til dig.
Rebecca Jozwiak: Ja, vi har mange rigtig gode publikumsspørgsmål her. Og David, denne blev specifikt stillet til dig. Det kommer fra nogen, der tilsyneladende har en vis erfaring med folk, der slags misbruger forespørgsler, og han siger slags, at jo mere vi styrker brugere, desto sværere er det at styre ansvarlig brug af beregne ressourcer. Så kan du forsvare dig mod udbredelse af forkert, men almindelige forespørgselsfraser?
David Crawford: Ja, jeg ser dette spørgsmål. Det er et godt spørgsmål - et vi får temmelig ofte. Jeg har set smerterne selv hos tidligere virksomheder, hvor du har brug for at uddanne brugere. For eksempel, “Dette er en log-tabel, det har logs, der går tilbage i årevis. Hvis du vil skrive en forespørgsel på denne tabel, er du virkelig nødt til at begrænse efter dato. ”Så det er for eksempel en uddannelse, jeg har gennemgået hos et tidligere firma, før jeg fik adgang til databasen.
Vi har et par måder, hvorpå vi forsøger at tackle dette. Jeg vil sige, at jeg synes, forespørgselslogdata er virkelig unikt værdifuldt til at tackle dem. Det giver en anden indsigt i forhold til, hvad databasen gør internt med sin forespørgselsplanlægning. Og hvad vi gør er en af disse interventioner - vi har de manuelle interventioner, som jeg viste, og det er nyttigt, ikke? Så på en bestemt sammenføjning, for eksempel, kan du sige, "Lad os afskrive dette." Det har et stort rødt flag, når det vises i smart suggest. Så det er en måde at forsøge at komme til mennesker på.
En anden ting, vi gør, er at automatisere ved udførelse-tid-interventioner. Det vil faktisk bruge parse-træet på forespørgslen, før vi kører det for at se, inkluderer det et bestemt filter eller et par andre ting, som vi også gør der. Men en af de mest værdifulde og den enkleste at forklare er, inkluderer det et filter? Så som det eksempel, jeg lige har givet, denne log-tabel, hvis du vil forespørge den, skal have et datointerval, kan du på tabellsiden angive, at du har mandat til, at datointervallet skal anvendes. Hvis nogen forsøger at køre en forespørgsel, der ikke inkluderer dette filter, vil det faktisk stoppe dem med en stor advarsel, og den vil sige, "Du skal sandsynligvis tilføje nogle SQL, der ser sådan ud til din forespørgsel." De kan fortsætte hvis de vil have. Vi vil faktisk ikke helt forbyde dem at bruge den - det er også en forespørgsel, den skal til sidst på dagen køre forespørgsler. Men vi sætter en temmelig stor barriere foran dem, og vi giver dem et forslag, et konkret anvendeligt forslag til at ændre forespørgslen for at forbedre deres ydeevne.
Det gør vi faktisk også automatisk i nogle tilfælde igen ved at observere forespørgselsloggen. Hvis vi ser, at nogle virkelig store procentdel af forespørgsler på denne tabel drager fordel af et bestemt filter eller en bestemt sammenføjningsklausul, vil vi faktisk poppe det op. Vi vil fremme det til en intervention. Faktisk skete det for mig på et internt datasæt. Vi har kundedata, og vi har bruger-id'er, men bruger-id'et er indstillet, da det er slags - vi har bruger-id'er til hver kunde. Det er ikke unikt, så du skal parre det med et klient-id for at få en unik sammenknytningsnøgle. Og jeg skrev en forespørgsel, og jeg prøvede at analysere noget, og det dukkede op og sagde: ”Hej, alle andre ser ud til at deltage i disse tabeller med både klient-id og bruger-id. Er du sikker på, at du ikke vil gøre det? ”Og det forhindrede mig faktisk i at foretage en forkert analyse. Så det fungerer både til nøjagtigheden af analysen såvel som for ydeevnen. Så det er sådan, hvordan vi tager dette problem videre.
Rebecca Jozwiak: Det ser ud til at være effektivt. Du sagde, at du ikke nødvendigvis vil forhindre folk i at samle ressourcer, men lærer dem slags, at det, de laver, måske ikke er det bedste, ikke?
David Crawford: Vi antager altid, at brugerne ikke er ondsindede - give dem de bedste formål - og vi prøver at være temmelig åbne på den måde.
Rebecca Jozwiak: Okay. Her er et andet spørgsmål: “Hvad er forskellen mellem en katalogadministrator, som med din løsning, og et MDM-værktøj? Eller er den faktisk afhængig af en anden hovedstol ved at udvide valget af forespørgselstabeller, hvorimod MDM ville gøre det automatisk, men med den samme underliggende princip for at indsamle metadata. "
David Crawford: Ja, jeg tror, at når jeg ser på traditionelle MDM-løsninger, er den primære forskel filosofisk. Det handler om, hvem brugeren er. Som jeg sagde i begyndelsen af min præsentation, Alation, jeg tror, da vi blev grundlagt, blev vi grundlagt med det mål at gøre det muligt for analytikere at producere mere indsigt, at producere dem hurtigere, at være mere præcise i den indsigt, de fremstille. Jeg tror ikke, det nogensinde har været målet med en traditionel MDM-løsning. Disse løsninger har en tendens til at være målrettet mod mennesker, der har brug for at udarbejde rapporter om, hvilke data der er indfanget til SCC eller internt til en anden form for revisionsformål. Det kan undertiden aktivere analytikere, men det er oftere, hvis det vil gøre det muligt for en udøver i deres arbejde, er det mere sandsynligt, at det aktiverer en dataarkitekt som en DBA.
Når du tænker på ting fra en analytikers synspunkt, er det, når du begynder at bygge et forespørgselsværktøj, som et MDM-værktøj aldrig ville gøre. Det er, når du begynder at tænke på præstation såvel som nøjagtighed samt forstå, hvad data relaterer til mit forretningsbehov. Alle disse ting er ting, der slags pop i vores sind, når vi designer værktøjet. Det går ind i vores søgealgoritmer, det går ind i layoutet på katalogsiderne og evnen til at bidrage med viden fra hele organisationen. Det går ind i det faktum, at vi byggede forespørgselsværktøjet, og at vi byggede kataloget direkte ind i det, så jeg tror, det virkelig kommer fra det. Hvilken bruger har du først i tankerne?
Rebecca Jozwiak: Okay, god. Det hjalp virkelig med at forklare det. der var ved at dø for at få fat i arkiverne, fordi han måtte forlade, men han ville virkelig, at hans spørgsmål blev besvaret. Han sagde, at det blev nævnt i begyndelsen, at der er flere sprog, men er SQL det eneste sprog, der er gearet inden for Compose-komponenten?
David Crawford: Ja, det er sandt. Og en af de ting, som jeg har bemærket, da jeg slags var vidne til eksplosionen af de forskellige typer databaser, af dokumentdatabaser, grafdatabaser, af nøgleværdibutikker, er at de er virkelig magtfulde til applikationsudvikling. De kan tjene særlige behov der virkelig godt på bedre måder end relationelle databaser kan.
Men når du bringer det tilbage til dataanalyse, når du bringer det tilbage til - når du vil give disse oplysninger til folk, der vil gøre ad hoc-rapportering eller ad hoc-grave i dataene, at de altid vender tilbage til en relation, i det mindste interface for mennesker. En del af det er bare fordi SQL er lingua franca i dataanalyse, så det betyder for mennesker, det er også for de værktøjer, der integreres. Jeg tror, dette er grunden til, at SQL på Hadoop er så populær, og at der er så mange forsøg på at løse det, fordi det i slutningen af dagen er det, hvad folk ved. Der er sandsynligvis millioner af mennesker, der ved, hvordan man skriver SQL, og jeg vil ikke vove mig om millioner, der ved, hvordan man skriver en Mongo-aggregeringsrørledningsramme-forespørgsel. Og at det er et standardsprog, der bruges til integration på tværs af en rigtig bred vifte af platforme. Så alt det siger, vi bliver meget sjældent bedt om at gå uden for det, fordi dette er det interface, som de fleste analytikere bruger, og det er et sted, hvor vi fokuserede, især i Compose, at vi fokuserede på at skrive SQL.
Jeg vil sige datavidenskab er det sted, hvor de vove sig mest udenfor, og derfor får vi lejlighedsvis spørgsmål om at bruge gris eller SAS. Dette er ting, vi bestemt ikke håndterer i Compose, og som vi gerne vil fange i kataloget. Og jeg ser også R og Python. Vi har et par måder, hvorpå vi har lavet grænseflader, som du kan bruge de forespørgsler, der er skrevet i Alation inde i R- og Python-scripts, så da du ofte er dataforsker og arbejder på et script-sprog, kildedata findes i en relationsdatabase. Du starter med en SQL-forespørgsel, og derefter behandler du den videre og opretter grafer inde i R og Python. Og vi har lavet pakker, som du kan importere til disse scripts, der trækker forespørgsler eller forespørgselsresultaterne fra Alation, så du slags kan have en blandet arbejdsgang der.
Rebecca Jozwiak: Okay, fantastisk. Jeg ved, at vi er løbet lidt forbi toppen af timen, jeg vil bare stille et eller to spørgsmål mere. Jeg ved, at du talte om alle de forskellige systemer, som du kan oprette forbindelse til, men hvad angår eksternt hostede data og internt hostede data, kan det sammen søges i dit enkelt synspunkt, i din ene platform?
David Crawford: Sikker på. Der er nogle få måder at gøre det på. Jeg mener, eksternt vært, jeg kan forestille mig, jeg prøver at tænke over nøjagtigt, hvad det kan betyde. Det kan betyde en database, som nogen er vært i AWS for dig. Det kan betyde en offentlig datakilde fra data.gov. Vi opretter forbindelse direkte til databaser ved at logge ind, ligesom et andet program med, med en databasekonto, og det er sådan, vi udtrækker metadataene. Så hvis vi har en konto, og vi har en netværkshavn åben, kan vi komme til den. Og når vi ikke har disse ting, har vi noget, der kaldes en virtuel datakilde, der giver dig mulighed for i det væsentlige at skubbe dokumentation, hvad enten det er automatisk, ved at skrive dit eget stik, eller ved at udfylde det ved at gøre ligesom en CSV-upload, for at dokumentere dataene sammen med dine interne data. Det bliver alt placeret i søgemaskinen. Det bliver henvisningsbart inde i artikler og anden dokumentation og samtaler inde i systemet. Så det er sådan, vi håndterer, når vi ikke direkte kan oprette forbindelse til et system.
Rebecca Jozwiak: Okay, det giver mening. Jeg skyder bare et spørgsmål mere til dig. En deltager er der spørger: "Hvordan skal indholdet i et datakatalog valideres, verificeres eller vedligeholdes, når kildedata opdateres, når kildedata ændres osv."
David Crawford: Ja, det er et spørgsmål, vi får meget, og jeg tror, en af de ting, som vi - en af vores filosofier, som sagt, tror vi ikke, at brugerne er ondsindede. Vi antager, at de prøver at bidrage med den bedste viden. De vil ikke komme ind og bevidst vildlede folk om dataene. Hvis det er et problem i din organisation, er Alation måske ikke det rigtige værktøj til dig. Men hvis du antager gode intentioner fra brugerne, så tænker vi på det som noget, hvor opdateringerne kommer ind, og som regel, hvad vi gør, er at vi sætter en steward med ansvar for hvert dataobjekt eller hver sektion af dataene. Og vi kan underrette disse stewards, når der foretages ændringer i metadataene, og de kan håndtere det på den måde. De ser opdateringer komme ind, de validerer dem. Hvis de ikke har ret, kan de gå tilbage og ændre dem og informere og forhåbentlig endda nå ud til den bruger, der har bidraget med informationen og hjælpe dem med at lære.
Så det er den primære måde, vi tænker på at gøre det på. Denne form for forslag fra mængden og ledelse af stævne, så vi har nogle muligheder omkring det.
Rebecca Jozwiak: Okay, god. Og hvis du bare kunne lade folk vide, hvordan de bedst kan komme i gang med Alation, og hvor kan de henvende sig specifikt for at få mere info. Jeg ved, at du delte den ene bit.ly. Er det det bedste sted?
David Crawford: Alation.com/learnmore Jeg synes, det er en god måde at gå på. For at tilmelde dig en demo har Alation.com-webstedet mange gode ressourcer, kundepapirer og nyheder om vores løsning. Så jeg synes, det er et godt sted at starte. Du kan også e-maile.
Rebecca Jozwiak: Okay, fantastisk. Og jeg ved, deltagere, ked af, hvis jeg ikke kom til alle spørgsmålene i dag, men hvis ikke, vil de blive videresendt til David eller hans salgsteam eller nogen på Alation, så de kan bestemt hjælpe med at besvare dine spørgsmål og hjælpe med at forstå hvad Alation gør, eller hvad de gør bedst.
Og med det, folkens, vil jeg gå foran og underskrive os. Du kan altid finde arkiverne på InsideAnalysis.com. Du kan også finde det på Techopedia.com. De har en tendens til at opdatere lidt hurtigere, så tjek det bestemt. Og så meget tak til David Crawford, Dez Blanchfield og Robin Boor i dag. Det har været en god webcast. Og med det giver jeg dig farvel. Tak, folkens. Hej hej.
David Crawford: Tak.
