Av Techopedia Staff, 22. juni 2016
Takeaway: Vert Rebecca Jozwiak diskuterer fordelene med datakataloger med Dez Blanchfield, Robin Bloor og David Crawford.
Du må registrere deg for dette arrangementet for å se videoen. Registrer deg for å se videoen.
Rebecca Jozwiak: Mine damer og herrer, Hei og velkommen til Hot Technologies i 2016. I dag har vi, “The Power of Suggestion: How a Data Catalog Empower Analysts.” Jeg er verten din Rebecca Jozwiak, og fyller ut for vår vanlige vert Eric Kavanagh i dag, mens han reiser verden rundt, så takk for at du ble med oss. Dette året er varmt, det er ikke bare varmt i Texas der jeg er, men det er varmt over alt. Det kommer en eksplosjon av alle slags nye teknologier. Vi har fått IoT, streaming av data, adopsjon av sky, Hadoop fortsetter å modnes og bli adoptert. Vi har automatisering, maskinlæring, og alt dette er selvfølgelig understreket av data. Og bedrifter blir mer og mer data drevet av dagen. Og selvfølgelig, poenget med det er å føre til kunnskap og oppdagelse, og du vet bedre beslutninger. Men for å virkelig få mest mulig utbytte av data, må det være lett å komme til. Hvis du holder den låst bort, eller begravet, eller i hjernen til noen få mennesker i bedriften, vil det ikke gjøre mye bra for bedriften som helhet.
Og jeg tenkte på datakatalogisering og tenkte selvfølgelig på biblioteker, hvor det for lengst var der du dro hvis du trengte å finne noe, om du hadde behov for å undersøke et emne, eller slå opp litt informasjon, du dro til biblioteket, og selvfølgelig gikk du til kortkatalogen, eller den skitne damen som jobbet der. Men det var også gøy å slags vandre rundt, hvis du bare ville lete, og at du kanskje bare oppdager noe pent, kan du finne ut noen interessante fakta som du ikke visste, men hvis du virkelig trengte å finne noe ut, og du visste hva du lette etter, du trengte kortkatalogen, og selvfølgelig er foretakets ekvivalent en datakatalog, som kan bidra til å belyse all data for våre brukere å berike, oppdage, dele, konsumere og virkelig hjelpe folk kommer til data raskere og enklere.
Så i dag har vi Dez Blanchfield, vår egen dataforsker, og vi har doktor Robin Bloor, vår egen sjefanalytiker, vi har fått David Crawford fra Alation, som skal snakke om selskapets datakatalogiseringshistorie, men først vi kommer til å lede av med Dez. Dez, jeg sender ballen til deg, og gulvet er ditt.
Dez Blanchfield: Takk, takk for at du har meg i dag. Dette er en sak jeg er ekstremt interessert i, for nesten hver eneste organisasjon jeg møter i det daglige arbeidet mitt, finner jeg nøyaktig den samme saken som vi snakket veldig kort om i pre-show-skjebnen, og det er det de fleste organisasjoner som har vært i virksomhet i mer enn noen få år har en mengde data begravet rundt organisasjonen, forskjellige formater, og faktisk har jeg klienter som har datasett som går tilbake til Lotus Notes, databaser som fremdeles kjører i noen tilfeller som deres pseudo-interneter, og de løper alle inn i denne utfordringen med å faktisk finne hvor dataene deres er, og hvordan få tilgang til dem, hvem de skal gi tilgang til dem, når de skal gi tilgang til dem, og hvordan man bare katalog, og hvordan du får den til et sted der alle kan: A) være klar over hva som er der og hva som er i det, og B), hvordan få tilgang til det og bruke det. Og en av de største utfordringene er selvfølgelig å finne den, den andre store utfordringen er å vite hva som er der inne og hvordan du får tilgang til det.
Jeg vet godt at jeg har mange titalls databaser, men jeg vet faktisk ikke hva som er der inne, eller hvordan jeg finner ut hva som er der, og så alltid når vi oppdager nå i pre-show-dataene, har du en tendens til å gå rundt på kontoret og stille spørsmål, og rope over de kubiske veggene og prøve å finne ut, ofte er min erfaring at du til og med finner ut at du vandrer til resepsjonen, resepsjonen og spør om noen vet hvem du kommer til å snakke med. Ganske ofte er det ikke alltid IT-folk fordi de ikke er klar over datasettet fordi noen nettopp har opprettet det, og det kan være noe enkelt som et - ganske ofte vil vi finne et prosjekt av noe slag som står opp i IT-miljøet og prosjektlederen brukte et regneark med alle ting, og det har fått en enorm mengde verdifull informasjon rundt eiendeler og kontekst og navn, og med mindre du kjenner til prosjektet og kjenner personen, kan du bare ikke finne den informasjonen. Det er bare ikke tilgjengelig, og du må få tak i den originale filen.
Det er en setning som har blitt anstrengt med tanke på data, og jeg er ikke nødvendigvis enig i det, men jeg synes det er en søt liten kast, og det er at en viss mengde mennesker tror at data er den nye oljen, og jeg at vi kommer til å dekke det på et eller annet aspekt også senere i dag. Men det jeg har lagt merke til, absolutt å være en del av den transformasjonen, er at organisasjoner av virksomheter som har lært å verdsette dataene sine, har fått betydelig fordel i forhold til konkurrentene.
Det var en interessant artikkel fra IBM, for rundt fem-seks år siden, og de undersøkte rundt 4000 selskaper her i Australia, og de tok all informasjon, alle resultatdata, alle finansdata og satte den sammen i en kokende gryte og deretter sendte den til Australian School of Economics, og de startet faktisk en vanlig trend her, og det var at selskaper som utnyttet teknologi alltid fikk et så konkurransefortrinn over sine jevnaldrende og konkurrenter i seg selv at konkurrentene nesten aldri fanger opp, og jeg tror det er veldig tilfelle nå med data som vi har sett det folk kaller en digital transformasjon der organisasjoner som tydelig har funnet ut hvordan de kan finne data de har, gjøre disse dataene tilgjengelige og gjøre dem tilgjengelige i noen veldig enkle forbruksvarer mote for organisasjonen, uten å nødvendigvis alltid vite hvorfor organisasjonen kan trenge den, og få betydelig fordel i forhold til konkurrenter.
Jeg har et par eksempler på dette lysbildet, som du kan se. Min ene linje er at den store forstyrrelsen i nesten alle bransjer etter mitt syn blir drevet av data, og hvis dagens trender er noe å gå etter, er mitt syn at vi bare har fått startet fordi når de mangeårige merkene endelig våkner opp til hva dette betyr og går inn i spillet, de kommer til å delta i engrosgrensen. Når slags store forhandlere som har fjell av data, begynner å bruke noen historiske analyser på dataene, hvis de til og med vet at de eksisterer, så vil noen av de elektroniske spillerne få litt av en vekker.
Men med mange av de fleste av disse merkene, mener jeg at vi har Uber som er det største drosjeselskapet i verden. De eier ingen drosjer, så hva er det som gjør dem magiske, hva er dataene deres? Airbnb, den største overnattingsleverandøren, har vi WeChat, det største telefonselskapet i verden, men de har ingen faktisk infrastruktur og ingen telefoner, ingen telefonlinjer. Alibaba, den største forhandleren på planeten, men de eier ikke noe av varelageret. Facebook, det største medieselskapet i ordet. Jeg tror at ved siste opptelling hadde de 1, 4 milliarder aktive databrukere nå, noe som er et overveldende tall. Det er ikke noe sted i nærheten - jeg tror noen hevdet at en fjerdedel av planeten faktisk er der hver dag, og likevel er her en innholdsleverandør som faktisk ikke lager innholdet, alle dataene de serverer er ikke opprettet av dem, de er opprettet av abonnentene deres, og vi kjenner alle til denne modellen.
SocietyOne, som du kanskje eller ikke har hørt om, det er et lokalt merke, jeg tror i et par land det er en bank som faktisk utfører utlån til fagfeller, så med andre ord har den ingen penger. Alt det gjør er at det administrerer transaksjonene og dataene sitter under den. Netflix, vi er alle veldig, veldig kjent med det. Det er en interessant foring her. Når Netflix lovlig kunne brukes i Australia, da det offisielt ble kunngjort, behøvde du ikke å bruke en VPN for å komme til det, pleier det mange mennesker rundt om i verden - hvis du ikke klarer å få det til i ditt lokale område - da Netfix ble lansert i Australia, økte den den internasjonale båndbredden på internettkoblingene våre med 40 prosent, slik at den nesten doblet internettbruken i Australia over natten, med bare en applikasjon, en skybasert applikasjon som ikke gjør annet enn å leke med data. Det er bare en overveldende statistikk.
Og selvfølgelig er vi alle kjent med Apple og Google, men dette er de største programvarevirksomhetene på planeten, men de skriver faktisk ikke appene. Hva er den konsekvente tingen med alle disse organisasjonene? Det er data, og de kom ikke dit fordi de ikke visste hvor dataene deres var, og de visste ikke hvordan de skulle katalogisere dem.
Det vi finner ut nå, er at det er denne nye aktivaklassen som kalles data, og selskapene våkner opp til det. Men de har ikke alltid verktøyene og kunnskapen og hvorfor til å kartlegge alle disse dataene, for å katalogisere alle disse dataene og gjøre dem tilgjengelige, men vi har funnet ut at selskaper med nesten ingen fysiske eiendeler har fått høy markedsverdi i ta opp tid via denne nye dataklassen. Som jeg har sagt, noen av de gamle spillerne våkner nå opp til dette og får det sikkert frem.
Jeg er en stor fan av å ta folk med på en liten tur, så i de atten hundre, sene atten hundre, og du vil være mer enn kjent med dette i det amerikanske markedet, viste det seg at for å føre en folketelling hvert år, tror jeg at de kjørte dem hvert tiende år på det tidspunktet, men hvis du skal føre folketelling hvert år, kan det ta opp til åtte eller ni år å faktisk gjøre dataanalysen. Det viste seg at det datasettet da slapp igjen i bokser på steder i papir, og nesten ingen kunne finne det. De fortsatte å pumpe ut disse rapportene, men de faktiske dataene var veldig vanskelig å få til, vi har en lignende situasjon med et annet verdensmessig øyeblikk, rundt 1940-tallet, med andre verdenskrig, og denne tingen er Bletchley Park Bombe stavet BOMBE, og det var et massivt analytisk verktøy som skulle knuses, som ville gå gjennom små datasett og finne signaler i det, og bli brukt til å hjelpe til med å knekke koder gjennom Enigma.
Denne tingen igjen, var egentlig en enhet designet, ikke mye for å katalogisere, men for å merke og kartlegge data, og gjøre det mulig å ta mønstre og finne dem inne i datasettene, i dette tilfellet bryte koder, finne nøkler og uttrykk og finne dem regelmessig i datasettene, og derfor har vi vært gjennom denne reisen med å finne ting i data, og lede mot katalogisering av data.
Og så fulgte disse tingene sammen, disse enorme lavkostnadsstativene med maskiner, bare hyller. Og vi gjorde noen veldig interessante ting, og en av tingene vi gjorde med dem er at vi bygde veldig lave kostnadsklynger som kunne begynne å indeksere planeten, og veldig kjent er disse store merkene som har kommet og gått, men sannsynligvis er Googles det vanligste hjemmet merkevare som vi alle har hørt om - det har blitt et faktisk verb, og du vet at du lykkes når merkevaren din blir et verb. Men det Google lærte oss, uten å innse det, muligens i næringslivet, er at de var i stand til å indeksere hele planeten til et visst nivå, og katalogisere dataene som var rundt om i verden, og gjøre den tilgjengelig på et veldig enkelt, praktisk form i en liten ørliten formel, en webside med nesten ingenting på den, og du skriver inn spørringen, den går og finner den fordi de allerede hadde gjennomsøkt planeten, indeksert den og gjort den lett tilgjengelig.
Og det vi la merke til, var: ”Hold på, vi gjør ikke dette i organisasjoner - hvorfor er det? Hvorfor er det at vi har en organisasjon som kan kartlegge hele planeten og indeksere den, gjennomsøke og indeksere den, og gjøre den tilgjengelig, vi kan søke etter den, og deretter klikke på saken for å finne den, hvordan kommer vi har ikke gjort det internt? ”Så det er mange av disse små stativene av maskiner rundt om i verden nå som gjør det for intranett og finner ting, men de er fremdeles bare i ferd med å få tak i ideen om å gå utover det tradisjonelle nettet. side, eller en filserver.
I stedet for å nå gå inn på denne neste generasjon datakatalog på mange måter, er det ikke egentlig noen passende metode for dataoppdagelse og katalogisering å oppdage datatilgang via post-it-lapper og vannavkjølende samtaler. virkelig var. Vi kan ikke lenger føre hele utfordringen til folk som bare sender notater, legger ut notater og chatter om det. Vi er vel og virkelig utenfor området der denne neste generelle tilnærmingen til datakatalogisering har kommet og gått. Vi må få armene rundt det. Hvis dette var et enkelt problem, ville vi allerede løst det på mange måter tidligere, men jeg tror at det ikke er et lett problem, bare å indeksere og ringe dataene er bare en del av det, vite hva som er i dataene og bygge metadata rundt det vi oppdager, og deretter gjøre det tilgjengelig i en lett, forbruksform, spesielt til selvbetjening og analyse. Det er fremdeles et problem å bli løst, men mange deler av puslespillet om fem år er godt og virkelig løst og tilgjengelig.
Som vi vet, er mennesker som katalogiserer data en oppskrift på feil fordi menneskelige feil er et av de største mareritt vi har å gjøre med i databehandling, og jeg snakker jevnlig om dette emnet der mennesker etter mitt syn antagelig fyller ut papirskjemaer er det største marerittet vi arbeider med big data og analyse, til å hele tiden måtte fikse tingene de gjør, til og med til enkle ting som datoer og felt, og folk setter dem i feil format.
Men som sagt, vi har sett søkemotorer på internett indeksere verden hver dag, så nå gjør vi det for ideen om at det kan gjøres på forretningsdatasett i oppdagelsesprosessen, og verktøy og systemer er nå lett tilgjengelig slik du skal lære i dag. Så trikset, virkelig etter mitt syn, er å velge riktige verktøy, de beste verktøyene for jobben. Og mer passende på toppen av det, å finne den rette delen av den for å hjelpe deg med å komme i gang denne veien. Og jeg tror vi kommer til å høre om det i dag, men før vi gjør det, skal jeg overføre til høgskolen min, Robin Bloor, og høre hans omtale av emnet. Robin, kan jeg overføre til deg?
Robin Bloor: Ja, det kan du absolutt. La oss se om dette fungerer, ja det gjør det. Ok, jeg kommer fra en annen retning enn Dez egentlig, men jeg havner på samme sted. Dette handler om å koble til data, så jeg tenkte bare at jeg skulle gå gjennom virkeligheten av å koble til data, punkt for punkt virkelig.
Det er et faktum at data er mer fragmentert enn de noen gang har vært. Datamengden vokser fenomenalt, men faktisk vokser de forskjellige datakildene også utrolig, og derfor blir data stadig fragmentert hele tiden. Men på grunn av analytiske applikasjoner spesielt - men det er ikke de eneste applikasjonene - har vi fått en veldig god grunn til å koble oss til alle disse dataene, så vi sitter fast på et vanskelig sted, og vi sitter fast i en verden av fragmenterte data, og det er mulighet i dataene som Dez kalte det, den nye oljen.
Om data, vel, det pleide å leve på spinnende disk, enten i filsystemer eller databaser. Nå lever det i et mye mer variert miljø, det lever i filsystemer, men det lever også i Hadoop-tilfeller i dag, eller til og med Spark-forekomster. Den lever i flere databaser. For ikke så lenge siden standardiserte vi litt relasjonsdatabase, du vet at de gikk ut av vinduet de siste fem årene, fordi det er behov for dokumentdatabaser, og det er behov for grafdatabaser, så du vet, spillet har endret. Så den levde på spinningsdisk, men den lever nå på SSD. Den siste mengden SSD - definitivt den siste SSD-enheten kommer ut fra Samsung - tjue gigabyte, noe som er enormt. Nå lever det i minnet, i den forstand at den viktigste kopien av data kan være i minnet, i stedet for på disk, brukte vi ikke til å bygge systemer som det; det gjør vi nå. Og den lever i skyen. Noe som betyr at det kan leve i noen av disse tingene, i skyen, vil du ikke nødvendigvis vite hvor det er i en sky, du vil bare ha adressen.
Bare for å ramse hjem poenget, har Hadoop så langt mislyktes som en utvidbar datalager. Vi hadde håpet at det skulle bli en utvidbar skala ut datalager, og det ville bare bli ett filsystem for alt, og det ville - regnbuer ville dukke opp på himmelen, i utgangspunktet, og enhjørninger ville danse rundt, og ingenting av det skjedde. Noe som betyr at vi ender opp med et problem med datatransport, og det er ikke nødvendigvis behov for datatransport til tider, men det er også vanskelig. Data har virkelig tyngde nå for tiden, når du først har kommet inn på flere terabyte med data, plukket den opp og kastet den rundt, slags årsaker til at forsinkelser vises i nettverket ditt eller vises på forskjellige steder. Hvis du vil transportere data rundt, er timing en faktor. Det er nesten alltid, i dag, noen grenser for hvor mye tid du har til å få en ting, en data fra et sted til et annet sted. Det pleide å være det vi pleide å tenke på som batchvinduer, når maskinen var slags inaktiv, og uansett hvor mye data du hadde, kunne du bare kaste den rundt og alt skulle fungere. Vel, det er borte, vi lever i en mye mer en sanntids verden. Derfor er timing en faktor. Så snart du vil flytte data rundt, så hvis dataene har tyngdekraft, kan du sannsynligvis ikke flytte dem.
Datahåndtering er en faktor i den forstand at du faktisk må håndtere alle disse dataene, du får ikke det gratis, og replikering kan være nødvendig for å faktisk få dataene til å gjøre den jobben den trenger å gjøre, fordi det kan ikke være hvor du har sagt det. Det kan hende det ikke har tilstrekkelige ressurser til å utføre normal behandling av dataene. Så data blir kopiert, og data blir kopiert mer enn du kan forestille deg. Jeg tror noen fortalte meg for lenge siden at det gjennomsnittlige stykke data er replisert minst to og en halv gang. ESBs eller Kafka presenterer et alternativ for dataflyt, men i dag krever det arkitektur. Nå for tiden må du virkelig tenke på en eller annen måte, hva det faktisk betyr å kaste dataene rundt. Derfor er det å foretrekke å få tilgang til data der det er, så lenge du selvfølgelig kan få den ytelsen du trenger når du faktisk søker etter dataene, og det avhenger av kontekst. Så det er en vanskelig situasjon, uansett. Når det gjelder dataspørsmål, pleide vi å kunne tenke på SQL, vi har kommet opp virkelig nå, du vet, forskjellige former for spørsmål, SQL ja, men tilstøtende, også grafiske spørsmål, Spark er bare ett eksempel på gjør graf, fordi vi også trenger å søke etter tekst, mer enn vi noen gang har gjort, også regex-type søk, som er virkelig kompliserte søk etter mønstre, og ekte mønster-matching, alle disse tingene bobler faktisk av. Og alle av dem er nyttige fordi de får deg det du leter etter, eller de kan skaffe deg det du leter etter.
Spørsmål nå dager spenner over flere data, så det gjorde ikke alltid det, og ofte er ytelsen rystende hvis du gjør det. Så det kommer an på omstendighetene, men folk regner med å kunne spørre om data fra flere datakilder, slik at dataoverføring av en eller annen type blir mer og mer aktuell. Datavirtualisering, som er en annen måte å gjøre det på, avhengig av ytelse, er også veldig vanlig. Datasøk er faktisk en del av en prosess, ikke hele prosessen. Det er bare verdt å påpeke at hvis du faktisk ser på analyseytelsen, kan den faktiske analysen ta veldig mye lenger tid enn datainnsamlingen, fordi det avhenger av omstendighetene, men dataforespørsler er en absolutt nødvendighet hvis du vil gjøre noe slags analyser på flere datakilder, og det bare, du må faktisk ha muligheter som spenner over.
Så om kataloger. Kataloger eksisterer av en grunn, i det minste sier vi at, du vet, det er, vi har kataloger, og vi har skjemaer i databaser, og vi har hver katalog, og vi har uansett hvor du går, du vil finne et sted og så vil du faktisk finner ut at det er en slags katalog, og den samlede globale katalogen er en så åpenbar god idé. Men veldig få selskaper har noe slikt. Jeg husker, tilbake i år to tusen - året to tusen panikk - jeg husker at kommunister ikke engang kunne slå fast hvor mange kjørbare de hadde, ikke noe imot hvor mange forskjellige datalagre de hadde, og det er nok tilfelle nå, du vet, at de fleste selskaper ikke aktivt vet i global forstand, hvilke data de har. Men det blir tydeligvis stadig mer nødvendig å faktisk ha en global katalog, eller i det minste å ha et globalt bilde av hva som foregår på grunn av veksten av datakilder, og den fortsatte veksten av applikasjoner, og det er spesielt nødvendig for analyse, fordi du også på en måte, og det er andre problemer her som avstamning og problemer med dataene, og det er nødvendig for sikkerhet, mange aspekter av datastyringen, hvis du virkelig ikke vet hvilke data du har, ideen at du skal styre det er bare absurd. Så i det at alle data er katalogisert på noen måte er bare et faktum. Spørsmålet er om katalogen er sammenhengende, og faktisk hva du kan gjøre med den. Så jeg skal vende tilbake til Rebecca.
Rebecca Jozwiak: Ok, takk Robin. Neste gang har vi fått David Crawford fra Alation, David. Jeg skal gå foran og sende ballen til deg, så kan du ta den bort.
David Crawford: tusen takk. Jeg setter veldig pris på dere som har meg på dette showet. Jeg tror jeg kommer til å sette i gang med dette, så jeg tror min rolle her er å ta litt av den teorien og se hvordan den faktisk blir brukt, og resultatene som vi klarer å drive hos ekte kunder og slik at du kan se noen få på lysbildet, vil jeg snakke om hvilke resultater vi vil kunne se i analytiske muligens forbedringer. Så for å motivere til diskusjonen, skal vi snakke om hvordan de kom dit. Så jeg er heldig som får jobbe ganske tett med mange veldig smarte mennesker, disse kundene, og jeg vil bare trekke frem noen få som har klart å måle, og snakke om hvordan det å ha en datakatalog har påvirket analytikeren deres arbeidsflyt. Og bare for å holde meg i fronten, tror jeg at en av tingene vi ser endres, med datakataloger vers tidligere medierte løsninger og en av måtene relasjoner virkelig tenker på løsningene vi har satt sammen, er å starte fra analytikerne og jobbe bakover. For å si det, la oss gjøre dette med å aktivere analytikernes produktivitet. I motsetning til bare overholdelse, eller i motsetning til bare å ha et varelager, lager vi et verktøy som gjør analytikere mer produktive.
Så når jeg snakker med en dataforsker ved finansserviceselskapet Square, er det en fyr, Nick, som fortalte oss om hvordan han hadde, han brukte flere timer på å finne det rette datasettet for å starte en rapport, nå kan han gjør det i løpet av sekunder ved å søke etter markedsandel, vi snakket med CTO deres som trakk analytikerne hans som brukte Square, unnskyld, brukte Alation, for å finne ut hva deres, hvilke fordeler de så, og de rapporterte om 50 prosent produktivitetsøkning, og at en av verdens beste forhandlere, eBay, har over tusen mennesker som gjør SQL-analyse med jevne mellomrom, og jeg jobber ganske tett med Deb Says der borte, som er prosjektet. manager i teamet for dataverktøy, og hun fant ut at når spørrere vedtar Alation, vedtar en katalog, ser de dobbelt så hastigheten som de skriver nye spørsmål mot databasen.
Så dette er virkelige resultater, dette er folk som faktisk bruker katalogen i organisasjonen, og jeg vil ta deg gjennom det som trengs for å få satt opp. Hvordan en katalog blir etablert i et selskap, og kanskje det viktigste å si, er at mye av det skjer automatisk, så Dez snakket om systemer, lærte om systemer, og det er akkurat hva en moderne datakatalog gjør. Så de installerer Alation i datasenteret, og deretter kobler de det til forskjellige kilder til metadata i datamiljøet. Jeg skal fokusere litt på databasene og BI-verktøyene - fra begge disse skal vi trekke ut tekniske metadata, om i utgangspunktet hva som finnes. Vel, så hvilke tabeller? Hvilke rapporter? Hva er rapportdefinisjonene? Så de trekker ut de tekniske metadataene, og en katalogside opprettes automatisk for hvert objekt inne i disse systemene, og deretter trekker de også ut og lag på toppen av de tekniske metadataene, de legger på toppen av bruksdataene. Det er først og fremst gjort ved å lese spørringslogger fra databasen, og dette er en veldig interessant informasjonskilde. Så når en analytiker skriver et spørsmål, når et rapporteringsverktøy, enten det er hjemmevokst eller utenfor sokkelen, om et rapporteringsverktøy kjører et spørsmål for å oppdatere dashbordet, når en applikasjon kjører en spørring for å sette inn data å operere på et datasett - alle disse tingene blir fanget opp i databasens spørringslogger. Enten du har en katalog eller ikke, blir de tatt i spørringsloggen med databasen. Hva en datakatalog kan gjøre, og spesielt hva Alasjonens katalog kan gjøre, er å lese loggene, stille spørsmålene inni dem og lage en virkelig interessant bruksgraf basert på disse loggene, og vi bringer den i spill for å informere fremtidige brukere av dataene om hvordan tidligere brukere av dataene har brukt dem.
Så vi bringer all den kunnskapen sammen til en katalog, og bare for å gjøre dette virkelig, er dette integrasjonene som allerede er distribuert hos kunder, så vi har sett Oracle, Teradata, Redshift, Vertica og en rekke andre relasjonsdatabaser. I Hadoop-verdenen er det en rekke SQL på Hadoop, slags relasjonelle, meta-butikker på toppen av Hadoop-filsystemet, Impala, Tez, Presto og Hive, vi har også sett suksess med sky-Hadoop private leverandører som Altiscale, og vi har også vært i stand til å koble til Tableau-servere, MicroStrategy-servere og indeksere dashbordene der, samt integrasjoner med data science kartverktøy som Plotly.
Så vi kobler til alle disse systemene, vi har koblet disse systemene til kunder, vi har dratt inn de tekniske metadataene, vi har dratt inn bruksdataene, og vi sorterer automatisk datakatalogen, men på den måten, vi sentraliserer kunnskapen, men bare sentraliserer ting i en datakatalog, gir ikke i seg selv de virkelig fantastiske produktivitetsforbedringene som vi snakket om med eBay, Square og markedsandel. For å gjøre det, må vi faktisk endre måten vi tenker å levere kunnskap til analytikere. Et av spørsmålene de stiller for å forberede seg på dette, var "Hvordan påvirker katalogen faktisk en analytikers arbeidsflyt?"
Det er det vi bruker hele dagen på å tenke på, og for å snakke om denne endringen i tenkning, om et trykk vers en pull-modell, ønsket jeg å lage en rask analogi til hvordan verden var før og etter å ha lest på en Kindle. Så det er bare en opplevelse noen av dere kan ha, når du leser en fysisk bok, du kommer over et ord, er du ikke sikker på at du kjenner ordets definisjon super godt, du kan kanskje gjette den fra kontekst, ikke så sannsynlig at du kommer til å reise deg fra sofaen, gå til bokhyllen din, finne ordboken din, støv den av og snu til rett sted i alfabetisk liste over ord for å sikre deg at, ja, du hadde den definisjonen helt riktig, og du vet nyansene av det. Så det skjer egentlig ikke. Så du kjøper en Kindle-app og begynner å lese bøker der, og du ser et ord du ikke er helt sikker på og du berører ordet. Helt plutselig, akkurat i den samme skjermen, er ordbokdefinisjonen av ordet, med alle dets nyanser, forskjellige eksempler på bruk, og du sveiper litt, og du får en Wikipedia-artikkel om det emnet, sveiper du igjen, du får et oversettelsesverktøy som kan oversette det til andre språk eller fra andre språk, og plutselig er kunnskapen din om språket så mye rikere, og det skjer bare utrolig mange ganger, sammenlignet med når du måtte gå og dra den ressursen for deg selv.
Og det jeg kommer til å argumentere, er at arbeidsflyten for en analytiker og måten en analytiker vil håndtere datadokumentasjon, faktisk er veldig likt hvordan en leser vil samhandle med ordboken, enten den er en fysisk, eller om Tenne, og så hva vi, slik vi virkelig så dette produktivitetsøkningen, ikke søl katalogen, men koble den til arbeidsflyten til analytikeren, og de har bedt meg om å gjøre en demo her, og jeg vil å gjøre det til fokus for denne presentasjonen. Men jeg vil bare sette opp konteksten for demoen. Når vi tenker på å skyve datakunnskapen til brukerne når de trenger det, tror vi det rette stedet å gjøre det, stedet hvor de tilbringer tiden sin og hvor de gjør analysen, er et SQL-spørringsverktøy. Et sted hvor du skriver og kjører SQL-spørringer. Så vi bygde et, og vi bygde det, og det som virkelig er annerledes med det fra andre spørringsverktøy, er dens dype integrering med datakatalogen.
Så spørringsverktøyet vårt kalles Alation Compose. Det er et nettbasert spørringsverktøy, og jeg vil vise det til deg om et sekund. Et nettbasert spørringsverktøy som fungerer på tvers av alle databaselogoer som du så på forrige lysbilde. Det jeg skal prøve å demonstrere spesielt er måten kataloginformasjonen kommer til brukere. Og det gjør det på denne typen tre forskjellige måter. Det gjør det gjennom intervensjoner, og det er der noen som er en datadministrator, eller en datatyrmann, eller en slags administrator på en eller annen måte, eller en leder, kan si: "Jeg vil slags avbryte med et notat eller en advarsel i arbeidsflyten og sørg for at den blir levert til brukere til rett tid. ”Så det er en intervensjon, og vi vil vise det.
Smarte forslag er en måte der verktøyet bruker all sin samlede kunnskap om katalogen for å foreslå objekter og deler av et spørsmål mens du skriver det. Det viktigste å vite det er at det virkelig drar nytte av spørringsloggen for å gjøre det, for å foreslå ting basert på bruk og også for å finne til og med deler av spørsmål som har blitt skrevet før. Og det skal vi vise.
Og forhåndsvisninger. Når du skriver inn navnet på et objekt, viser vi deg alt som katalogen vet, eller i det minste de mest relevante tingene som katalogen vet om det objektet. Så prøver av dataene, som hadde brukt det før, det logiske navnet og beskrivelsen av dette objektet, kommer opp til deg mens du skriver det uten å måtte be om det.
Så uten å snakke mer, kommer jeg til demoen, og jeg bare venter på at den skal vises. Det jeg skal vise deg her er spørringsverktøyet. Det er et dedikert SQL-skrivegrensesnitt. Det er et eget grensesnitt fra katalogen, i en viss forstand. Dez og Robin snakket om katalogen, og jeg hopper litt over kataloggrensesnittet rett på hvordan den bringes direkte inn for å betjene arbeidsflyten.
Jeg viser bare et sted der jeg kan skrive SQL, og nederst ser du at vi slags har litt informasjon om objektene vi henviser til. Så jeg bare begynner å skrive en spørring, og jeg vil slutte når jeg kommer til et av disse inngrepene. Så jeg skriver "select", og jeg vil ha året. Jeg vil ha navnet. Og jeg skal slå opp litt lønnsdata. Så dette er et utdanningsdatasett. Den har informasjon om institusjoner for høyere utdanning, og jeg ser på den gjennomsnittlige fakultetslønnen som er i en av disse tabellene.
Så jeg har faktisk skrevet ordet “lønn.” Det er ikke akkurat i navnet på kolonnen på den måten. Vi bruker både de logiske metadataene og de fysiske metadatene for å komme med forslag. Og det jeg vil påpeke her, er denne gule boksen som vises her. Det står at det er en advarsel i denne kolonnen. Jeg gikk ikke og lette etter det, jeg tok ikke en klasse i hvordan jeg bruker disse dataene riktig. Det kom til meg, og det hender å være en advarsel om en konfidensialitetsavtale som har med disse dataene å gjøre. Så det er noen regler for utlevering. Hvis jeg skal spørre om disse dataene, vil jeg ta data ut av denne tabellen, jeg bør være forsiktig med hvordan jeg røper dem. Så du har en styringspolitikk her. Det er noen overholdelsesutfordringer som gjør det så mye lettere å overholde denne policyen når jeg vet om den på det tidspunktet jeg ser på dataene.
Så jeg har fått det til meg, og så skal jeg også se på undervisning. Og her ser vi forhåndsvisningene komme i spill. På denne undervisningssøylen ser jeg - det er en undervisningssøyle på institusjonsbordet, og jeg ser en profil av det. Alation går og henter eksempeldata fra tabellene, og i dette tilfellet viser det meg noe som er ganske interessant. Det viser meg fordelingen av verdiene, og den viser meg at nullverdien dukket opp 45 ganger i prøven, og mer enn noen annen verdi. Så jeg har forståelse for at vi kanskje mangler noen data.
Hvis jeg er en avansert analytiker, kan dette være en del av arbeidsflyten min allerede. Spesielt hvis jeg er en særlig omhyggelig en, der jeg vil gjøre en haug med profileringsspørsmål i forkant. Hver gang jeg nærmer meg et nytt stykke data, tenker jeg alltid på hva datadekningen vår er. Men hvis jeg er ny på dataanalyse, hvis jeg er ny på dette datasettet, kan jeg anta at hvis det er en kolonne, er det fylt ut hele tiden. Eller jeg kan anta at hvis den ikke er fylt ut, ikke er null, er den null eller noe sånt. Men i dette tilfellet har vi mange nuller, og hvis jeg gjorde et gjennomsnitt, ville de sannsynligvis ta feil, hvis jeg bare antok at disse nullene faktisk var null i stedet for manglende data.
Men Alation, ved å bringe denne forhåndsvisningen inn i arbeidsflyten, ber du deg om å ta en titt på denne informasjonen og gir til og med en slags begynnende analytikere en sjanse til å se at det er noe å legge merke til her om disse dataene. Så vi har den forhåndsvisningen.
Det neste jeg skal gjøre er at jeg skal prøve å finne ut hvilke tabeller du kan få denne informasjonen fra. Så her ser vi de smarte forslagene. Det har pågått hele tiden, men spesielt her har jeg ikke en gang skrevet noe, men det vil foreslå for meg hvilke tabeller jeg kanskje vil bruke til denne spørringen. Og det viktigste å vite om dette er at det drar nytte av bruksstatistikken. Så i et miljø som for eksempel eBay, der du har hundretusenvis av bord i en enkelt database, har et verktøy som kan slags treffe hveten fra agnet og bruke disse bruksstatistikkene, er virkelig viktig for å lage disse forslag verdt noe.
Så det kommer til å foreslå denne tabellen. Når jeg ser på forhåndsvisningen, fremhever vi faktisk tre av kolonnene som jeg har nevnt allerede i spørringen. Så jeg vet at den har tre, men den har ikke navnet. Jeg trenger å få navnet, så jeg skal være med. Når jeg deltar, har jeg nå disse forhåndsvisningene som hjelper meg å finne, hvor er tabellen med navnet. Så jeg ser at denne har et pent formatert, slags ordentlig kapitalisert navn. Det ser ut til å ha en rad med et navn for hver institusjon, så jeg kommer til å ta tak i det, og nå trenger jeg en tilknytningstilstand.
Og så, her som Alation gjør, er å se tilbake på spørringsloggene, se tidligere ganger at disse to tabellene er blitt samlet, og foreslå forskjellige måter å bli med på. Nok en gang er det litt inngrep. Hvis jeg ser på en av disse, har den en advarsel som viser meg at dette bare skal brukes til samlet analyse. Det vil sannsynligvis produsere feil ting hvis du prøver å gjøre noe gjennom institusjonen etter institusjon. Mens denne, med OPE ID, blir godkjent som den riktige måten å bli med på disse to tabellene hvis du vil ha data på universitetsnivå. Så jeg gjør det, og det er en kort spørring, men jeg har skrevet spørringen uten å nødvendigvis ha noe innblikk i hva dataene er. Jeg har faktisk aldri sett på et ER-diagram over dette datasettet, men jeg vet ganske mye om disse dataene allerede fordi relevant informasjon kommer til meg.
Så det er slags tre måter som en katalog, gjennom et integrert spørringsverktøy, kan påvirke arbeidsflyten direkte når du skriver spørsmål. Men en av de andre fordelene med å ha et spørringsverktøy integrert med en katalog, er at når jeg er ferdig med spørringen og lagrer den, kan jeg sette en tittel som "Institusjonsundervisning og fakultetslønn, " og så har jeg en knapp her som lar meg bare publisere den i katalogen. Det blir veldig enkelt for meg å mate dette tilbake. Selv om jeg ikke publiserer den, blir den tatt som en del av spørringsloggen, men når jeg publiserer den, blir den faktisk en del av måten det sentraliserte stedet der all datakunnskap lever.
Så hvis jeg klikker på Søk etter alle spørsmål i Alation, kommer jeg til å bli tatt - og her ser du litt mer av kataloggrensesnittet - blir jeg ført til et dedikert søk som viser meg en måte å finne spørsmål på tvers av hele organisasjonen. Og du ser at min nylig publiserte spørring er på toppen. Og noen vil kanskje legge merke til her på, mens vi fanger spørsmålene, også fanger vi forfatterne, og vi oppretter slags forhold mellom meg som forfatter og disse dataobjektene som jeg nå vet noe om. Og jeg blir etablert som en ekspert på dette spørsmålet og på disse dataobjektene. Det er veldig nyttig når folk trenger å lære om data, og da kan de finne den rette personen å lære om. Og hvis jeg faktisk er ny på data, om jeg er en avansert analytiker - som en avansert analytiker, kan jeg se på dette og se en haug med eksempler som ville få meg i gang med et nytt datasett. Som noen som kanskje ikke føler seg superkyndige med SQL, kan jeg finne ferdiglagde spørsmål som er rapporter som jeg kan dra nytte av.
Her er en av Phil Mazanett om median SAT-score. Klikk på dette, så får jeg en slags katalogside for selve spørringen. Den snakker om en artikkel som ble skrevet som refererer til dette spørsmålet, så det er noe dokumentasjon for meg å lese hvis jeg vil lære å bruke det. Og jeg kan åpne det i spørringsverktøyet ved å klikke på Skriv-knappen, og jeg kan bare kjøre det selv her uten å redigere det. Og faktisk får du se litt av våre lette rapporteringsfunksjoner, der du når du skriver en spørring kan slippe inn en malvariabel som denne, og det skaper en enkel måte å lage et skjema for å utføre en spørring på på et par parametere.
Så det er det jeg har for demoen. Jeg kommer til å bytte tilbake til lysbildene. Bare for en slags oppsummering, viste vi hvordan en administrator, en datadministrator, kan gripe inn ved å plassere advarsler på objekter som dukker opp i spørringsverktøyet, hvordan Alation bruker sin kunnskap om bruken av dataobjekter for å gjøre smarte forslag, hvordan det bringer i profilering og andre tips for å forbedre arbeidsflytene til analytikere når de berører bestemte objekter, og hvordan alle den slags innmatinger går tilbake i katalogen når nye spørsmål blir skrevet.
Jeg er tydeligvis en talsperson på vegne av selskapet. Jeg skal si fine ting om datakataloger. Hvis du vil høre direkte fra en av våre kunder, driver Kristie Allen på Safeway et team av analytikere og har en veldig kul historie om en tid da hun trengte å virkelig slå klokka for å levere et markedsføringseksperiment, og hvordan hele hennes teamet brukte Alation for å samarbeide og snu seg veldig raskt om det prosjektet. Så du kan følge denne bit.ly-lenken for å sjekke historien, eller hvis du vil høre litt om hvordan Alation kan bringe en datakatalog inn i organisasjonen din, setter vi gjerne opp en personlig demo. Takk så mye.
Rebecca Jozwiak: Tusen takk, David. Jeg er sikker på at Dez og Robin har noen få spørsmål før jeg vender meg til publikumets spørsmål og svar. Dez, vil du gå først?
Dez Blanchfield: Absolutt. Jeg elsker ideen om dette konseptet med publiserte spørsmål og knytter det tilbake til forfatterkilden. Jeg har vært mangeårig forkjemper for denne ideen om en egen app-butikk, og jeg synes dette er et veldig flott grunnlag å bygge videre på.
Jeg kom til å få litt innsikt i noen av organisasjonene som du ser for å gjøre dette, og noen av suksesshistoriene de kan ha hatt med hele denne reisen, for ikke bare å utnytte verktøyet og plattformen din til å oppdage dataene, men også transformere sine interne kulturelle og atferdstrekk rundt. Nå som du har denne typen in-app-butikker der du bare laster ned, konseptet der de ikke bare bare kan finne det, men de kan faktisk begynne å utvikle små samfunn med de som holder den kunnskapen.
David Crawford: Ja, jeg tror vi har blitt overrasket. Vi tror på verdien av å dele spørsmål, både fra min fortid som produktansvarlig i Adtech og fra alle kundene som vi har snakket med, men jeg har fortsatt blitt overrasket over hvor ofte det er noe av det aller første som kundene snakk om som verdien de får ut av Alation.
Jeg foretok noen brukertesting av spørringsverktøyet hos en av kundene våre som het Invoice2go, og de hadde en produktansvarlig som var relativt ny, og de sa - han sa faktisk til meg, uten spørsmål under brukertesten, "Jeg ville faktisk ikke å skrive SQL i det hele tatt, bortsett fra at det er gjort enkelt av Alation. "Og selvfølgelig, som statsminister, går jeg litt:" Hva mener du, hvordan gjorde vi det? "Og han sa:" Vel, det er bare fordi jeg kan logge inn, og jeg kan se alle disse eksisterende spørsmålene. ”Å starte med en tom skifer med SQL er en utrolig vanskelig ting å gjøre, men å endre et eksisterende spørsmål der du kan se resultatet som er lagt ut og du kan si, "Åh, jeg trenger bare denne ekstra kolonnen, " eller "jeg trenger å filtrere den til et bestemt spekter av datoer", det er en mye enklere ting å gjøre.
Vi har sett slags slike tilleggsroller, som produktsjefer, kanskje folk i salgsopsjoner, som begynner å plukke opp, og som alltid ønsket å lære SQL og begynne å plukke den opp ved å bruke denne katalogen. Vi har også sett at mange selskaper har prøvd å gjøre en slags åpen kildekode. Jeg har prøvd å bygge slike ting internt, der de sporer spørsmålene og gjør dem tilgjengelige, og det er noen slags vanskelige designutfordringer for å gjøre dem nyttige. Facebook har hatt et internt verktøy som de kalte HiPal som slags fanget alle spørsmålene som er skrevet på Hive, men det du finner ut er at hvis du ikke snakker brukerne på riktig måte, så ender du opp med veldig lang liste over utvalgte utsagn. Og som en bruker som prøver å finne ut om et spørsmål er nyttig for meg eller om det er bra, hvis jeg bare ser gjennom en lang liste med utvalgte utsagn, vil det ta meg mye lengre tid å få noe uten verdi der enn starter fra bunnen av. Vi tenkte ganske nøye på hvordan du lager en spørrekatalog som bringer de riktige tingene foran og gir den på en nyttig måte.
Dez Blanchfield: Jeg tror vi alle går gjennom denne reisen fra en veldig ung alder, til voksen alder, på mange måter. En haug med teknologier. Jeg, personlig, har jeg gjennomgått den samme ekte tingen, som å lære å kutte koden. Jeg ville gå gjennom magasiner og deretter bøker, og jeg ville studere til et visst nivå, og så trengte jeg å gå og faktisk få litt mer trening og utdanning på det.
Men uforvarende fant jeg ut at selv når jeg skulle gå fra å lære meg selv og lese magasiner, lese bøker og hakke andre menneskers programmer og gå på kurs på det, endte jeg fremdeles med å lære like mye av å gjøre kursene som jeg bare snakket med andre mennesker som hadde noen opplevelser. Og jeg synes at det er en interessant oppdagelse at vi nå ser den samme parallellen, nå som du bringer det til dataanalyse, at mennesker alltid er ganske smarte.
Den andre tingen jeg virkelig er opptatt av å forstå er, på et veldig høyt nivå, mange organisasjoner kommer til å spørre: "Hvor lang tid tar det å komme til det punktet?" Hva er det tippepunktet tidsramme når folk kommer din plattform installert, og de begynte å oppdage verktøyene? Hvor raskt er det bare folk som ser at denne tingen blir til et virkelig øyeblikkelig "a-ha" øyeblikk der de innser at de ikke engang bekymrer seg for ROI lenger fordi det er der, men nå endrer de faktisk måten de gjør forretninger på ? Og de har oppdaget en tapt kunst, og de forventer at de kan gjøre noe virkelig, veldig gøy med det.
David Crawford: Ja, jeg kan ta litt på det. Jeg tror at når vi blir installert, at en av de fine tingene, en av de tingene som folk liker med en katalog som er direkte koblet inn i datasystemene, er at du ikke starter tomt der du må fylle den ut side for side. Og dette stemmer på forhånd med tidligere dataløsninger der du vil starte med et tomt verktøy og du må begynne å lage en side for alt du vil dokumentere.
Siden vi dokumenterer så mange ting automatisk ved å trekke ut metadataene, i det vesentlige i løpet av få dager etter at programvaren er installert, kan du ha et bilde av datamiljøet ditt som er minst 80 prosent der i verktøyet. Og så tror jeg så snart folk begynner å skrive spørsmål med verktøyet, lagres de automatisk tilbake i katalogen, og så vil de begynne å vises.
Jeg vil ikke være ivrig etter å si det. Jeg synes to uker er et ganske godt konservativt estimat, til en måned. To uker til en måned, konservativt estimat for å virkelig snu og føle at du får verdi ut av det, som at du begynner å dele litt kunnskap og kunne dra dit og finne ut ting om dataene dine.
Dez Blanchfield: Det er ganske utrolig, når du tenker på det. Det faktum at noen av de store dataplattformene du effektivt indekserer og katalogiserer, vil noen ganger ta opp til året å implementere og distribuere og stå opp ordentlig.
Det siste spørsmålet jeg har til deg før jeg overlater til Robin Bloor, er kontakter. En av tingene som umiddelbart hopper ut mot meg, er at du tydeligvis har fått en hel utfordring. Så det er et par spørsmål bare veldig raskt. Én, hvor raskt blir koblinger implementert? Åpenbart begynner du med den største plattformen, som Oracle og Teradatas og så videre og DB2s. Men hvor regelmessig ser du at nye kontakter kommer gjennom, og hvilken behandlingstid tar de? Jeg ser for meg at du har en standard ramme for dem. Og hvor dypt går du inn i disse? For eksempel Oracle's og IBMs i verden, og til og med Tereadata, og deretter noen av de mer populære av sene open source-plattformer. Jobber de direkte med deg? Oppdager dere det selv? Må du ha kunnskap om innsiden på disse plattformene?
Hvordan ser det ut for å utvikle en kontakt, og hvor dypt involverer du deg disse partnerskapene for å sikre at kontaktene oppdager alt du kan?
David Crawford: Ja, det er et flott spørsmål. Jeg tror at vi for det meste kan utvikle kontaktene. Det gjorde vi absolutt da vi var yngre og hadde ingen kunder. Vi kan utvikle forbindelsene absolutt uten å ha behov for intern tilgang. Vi får aldri noen spesiell tilgang til datasystemene som ikke er offentlig tilgjengelige, og ofte uten å ha noen innsideinformasjon. Vi drar fordel av metadatatjenestene som er tilgjengelig av datasystemene selv. Ofte kan de være ganske sammensatte og vanskelig å jobbe med. Jeg kjenner spesielt SQL Server, slik de administrerer spørringsloggen, det er flere forskjellige konfigurasjoner, og det er noe du virkelig må jobbe med. Du må forstå nyansene og knottene og ringe på den for å sette den opp ordentlig, og det er noe vi jobber med kunder på siden vi har gjort det flere ganger før.
Men til en viss grad er det slags offentlige API-er som er tilgjengelige eller offentlige grensesnitt som er tilgjengelige som vi utnytter. Vi har partnerskap med flere av disse selskapene, det er for det meste et grunnlag for sertifisering, slik at de føler seg komfortable med å si at vi jobber, og at de også kan gi oss ressurser for testing, noen ganger tidlig tilgang, kanskje til en plattform som kommer ut for å sikre at vi jobber med de nye versjonene.
For å snu en ny forbindelse, vil jeg si igjen, prøver å være konservativ, la oss si seks uker til to måneder. Det kommer an på hvor lik den er. Så noen av Postgre-verkene ser veldig ut som Redshift. Redshift og Vertica deler mye av detaljene sine. Så vi kan dra nytte av disse tingene. Men ja, seks uker til to måneder ville være rettferdig.
Vi har også API-er, slik at - vi tenker på Alation som en metadataplattform også, så hvis noe ikke er tilgjengelig for oss å nå ut og automatisk ta tak, er det måter du kan skrive kontakten selv og skyve den inn i systemet vårt slik at at alt fortsatt blir sentralisert i en enkelt søkemotor.
Dez Blanchfield: Fantastisk. Jeg setter pris på at. Så vi kommer til å overlate det til Robin, for jeg er sikker på at han også har en mengde spørsmål. Robin?
Rebecca Jozwiak: Robin kan være på stum.
Dez Blanchfield: Du har satt deg i ro.
Robin Bloor: Ja, ikke sant. Beklager, jeg dempet meg selv. Hva er prosessen når du implementerer dette? Jeg er litt nysgjerrig fordi det kan være mye data mange steder. Så hvordan fungerer det?
David Crawford: Ja, helt sikkert. Vi går inn, først er det en slags IT-prosess å sørge for at serveren vår er levert, sørge for at nettverkstilkoblinger er tilgjengelige, at portene er åpne slik at vi faktisk får tilgang til systemene. De vet ofte hvilke systemer de vil starte med. Å kjenne inne i et datasystem, som - og noen ganger vil vi faktisk hjelpe dem. Vi hjelper dem med å gå igjennom i spørringsloggen for å forstå hvem som bruker hva og hvor mange brukere de har på et system. Så vi hjelper deg med å finne ut hvor - de ofte, hvis de har hundrevis eller tusenvis av mennesker som kan logge seg på databaser, vet de faktisk ikke hvor de logger inn, så vi kan finne ut av spørrer logger hvor mange unike brukerkontoer du faktisk har logget på og utført spørsmål her i løpet av en måned.
Så vi kan dra nytte av det, men ofte bare på de viktigste. Vi får dem satt opp, og så er det en prosess med å si: "La oss prioritere." Det er en rekke aktiviteter som kan skje parallelt. Jeg vil fokusere på opplæringen for å bruke spørringsverktøyet. Når folk begynner å bruke spørringsverktøyet, er det først og fremst mange som elsker det faktum at det bare er et enkelt grensesnitt til alle de forskjellige systemene deres. De elsker også det faktum at det er nettbasert, og involverer ikke installasjoner hvis de ikke vil. Fra et sikkerhetsmessig synspunkt liker de å ha et slags inngangspunkt, fra et nettverkssynspunkt, mellom et slags IT-nettverk og datasenteret der datakildene for produksjonen bor. Og så vil de sette opp Alation som et søkeverktøy og begynne å bruke Compose som et tilgangspunkt for alle disse systemene.
Så når det skjer, er det vi fokuserer på trening, å forstå hva som er noen av forskjellene mellom et nettbasert eller et serverbasert spørringsverktøy i forhold til det du vil ha på skrivebordet ditt, og noen av nyansene ved å bruke at. Og samtidig som vi prøver å gjøre er å identifisere de mest verdifulle dataene, igjen dra nytte av informasjonen om spørringsloggen og si: “Hei, det kan være lurt å gå inn og hjelpe folk til å forstå disse. La oss begynne å publisere representative spørsmål på disse tabellene. ”Det er noen ganger den mest effektive måten å veldig raskt få folk spunnet opp. La oss se på din egen søkehistorie, publiser disse tingene slik at de vises som de første spørsmålene. Når folk ser på en tabellside, kan de se alle spørsmål som berørte tabellen, og de kan starte derfra. Og la oss begynne å legge til titler og beskrivelser til disse objektene slik at de er lettere å finne og søke, slik at du vet noen av nyansene i hvordan du bruker dem.
Vi sørger for at vi får en grundig titt på spørringsloggen slik at vi kan generere avstamning. Noe av det vi gjør er at vi ser gjennom spørringsloggen til tider når data flyttes fra en tabell til en annen, og som gjør at vi kan sette et av de mest stilte spørsmålene om en datatabell er, hvor kom dette fra? Hvordan stoler jeg på det? Og det vi kan vise er ikke bare hvilke andre tabeller det kom fra, men hvordan det ble transformert underveis. Igjen, dette er slags drevet av spørringsloggen.
Så vi sørger for at disse tingene er satt opp og at vi får avstamning til systemet, og vi målretter oss mot de mest verdifulle og de mest utnyttede metadataene som vi kan etablere på tabellsidene, slik at når du søker, finner du noe nyttig.
Robin Bloor: OK. Det andre spørsmålet - det er mange spørsmål fra publikum, så jeg vil ikke ta opp for mye av tiden her - det andre spørsmålet som den slags kommer til tankene er bare smertepunktene. Mye programvare er kjøpt fordi folk på en eller annen måte har problemer med noe. Så hva er det vanlige smertepunktet som fører folk til Alation?
David Crawford: Ja. Jeg tror det er noen få, men jeg tror at en av de som vi hører ganske ofte er analytiker ombord. "Jeg kommer til å trenge å ansette 10, 20, 30 personer på kort sikt som er nødt til å produsere ny innsikt fra disse dataene, hvordan skal de komme opp i fart?" Så analytiker ombord er noe vi absolutt vil takle. Det er også bare å avlaste senioranalytikerne fra å bruke all sin tid på å svare på spørsmål fra andre mennesker om data. Det er en veldig hyppig også. Og begge disse er i hovedsak utdanningsproblemer.
Og så vil jeg si et annet sted at vi ser at folk adopterer Alation er når de ønsker å sette opp et helt nytt datamiljø for noen å jobbe i. De vil annonsere og markedsføre dette internt for folk å dra nytte av. Å gjøre Alation til frontend for det nye analytiske miljøet er veldig tiltalende. Det har dokumentasjonen, det har et enkelt introduksjonspunkt til - et enkelt tilgangspunkt til systemene, og det er et annet sted der folk vil komme til oss.
Robin Bloor: Ok, jeg vil gi deg videre til Rebecca fordi publikum prøver å komme til deg.
Rebecca Jozwiak: Ja, vi har mange veldig gode publikumsspørsmål her. Og David, denne ble posert spesielt for deg. Det er fra noen som tilsynelatende har litt erfaring med folk som bruker misbruk av spørsmål, og han sier at mer jo vi styrker brukere, desto vanskeligere er det å styre ansvarlig bruk av beregne ressurser. Så kan du forsvare deg mot forplantning av misforståtte, men vanlige spørresetninger?
David Crawford: Ja, jeg ser dette spørsmålet. Det er et flott spørsmål - et vi får ganske ofte. Jeg har sett smertene selv hos tidligere selskaper, der du trenger å trene brukere. For eksempel, "Dette er en loggtabell, det er logger som går tilbake i flere år. Hvis du skal skrive en forespørsel på dette bordet, må du virkelig begrense etter dato. ”Så for eksempel er det en opplæring jeg har gjennomgått hos et tidligere selskap før jeg fikk tilgang til databasen.
Vi har et par måter vi prøver å løse dette på. Jeg vil si at jeg synes data om spørringslogg er veldig unike for å løse dem. Det gir en annen innsikt i forhold til hva databasen gjør internt med spørringsplanleggeren. Og hva vi gjør er, et av disse inngrepene - vi har de manuelle intervensjonene som jeg viste, og det er nyttig, ikke sant? Så på en bestemt sammenføyning, for eksempel, kan du si: "La oss avskrive dette." Det vil ha et stort rødt flagg når det vises i smart forslag. Så det er en måte å prøve å komme til mennesker på.
En annen ting vi gjør er å automatisere ved gjennomføringstidsintervensjoner. Det vil faktisk bruke analysetreet på spørringen før vi kjører det for å se, inkluderer det et visst filter eller et par andre ting vi også gjør der. Men noe av det mest verdifulle og det enkleste å forklare er, inkluderer det et filter? Så som det eksemplet jeg nettopp ga, denne loggtabellen, hvis du vil spørre den, må ha et datoperiode, kan du på tabellsiden angi at du gir mandat til at datoperiodesfilter skal brukes. Hvis noen prøver å kjøre en spørring som ikke inkluderer det filteret, vil det faktisk stoppe dem med en stor advarsel, og den vil si: "Du bør sannsynligvis legge til noen SQL som ser slik ut i spørringen." De kan fortsette hvis de vil ha. Vi har ikke til hensikt å forby dem helt fra å bruke den - det er også en spørring, den må på slutten av dagen kjøre spørsmål. Men vi legger en ganske stor barriere foran dem, og vi gir dem et forslag, et konkret anvendelig forslag for å endre spørringen for å forbedre ytelsen.
Vi gjør det også automatisk i noen tilfeller, igjen ved å observere spørringsloggen. Hvis vi ser at noen virkelig store prosentandeler av spørsmålene på denne tabellen drar fordel av et bestemt filter eller en bestemt sammenføyningsklausul, vil vi faktisk slå det opp. Vi vil promotere det til et inngrep. Det skjedde faktisk med meg på et internt datasett. Vi har kundedata og vi har bruker-ID-er, men bruker-ID-en er angitt, siden det er slags - vi har bruker-ID-er for hver kunde. Det er ikke unikt, så du må koble den med en klient-ID for å få en unik sammenkoblingsnøkkel. Og jeg skrev et spørsmål, og jeg prøvde å analysere noe, og det dukket opp og sa: “Hei, alle andre ser ut til å bli med i disse tabellene med både klient-ID og bruker-ID. Er du sikker på at du ikke vil gjøre det? ”Og det stoppet meg faktisk fra å gjøre noen uriktig analyse. Så det fungerer både for nøyaktigheten i analysen så vel som for ytelsen. Så det er på den måten hvordan vi tar det problemet videre.
Rebecca Jozwiak: Det ser ut til å være effektivt. Du sa at du ikke nødvendigvis vil hindre folk i å ta opp ressurser, men på en måte lære dem at det de gjør kanskje ikke er det beste, ikke sant?
David Crawford: Vi antar alltid at brukerne ikke er ondsinnet - gi dem det beste - og vi prøver å være ganske åpne på den måten.
Rebecca Jozwiak: Ok. Her er et annet spørsmål: "Hva er forskjellen mellom en katalogbehandler, som med løsningen din, og et MDM-verktøy? Eller er den faktisk avhengig av en annen rektor ved å utvide valget av spørretabellene, mens MDM vil gjøre det automatisk, men med samme underliggende prinsipp for å samle metadata. "
David Crawford: Ja, jeg tror at når jeg ser på tradisjonelle MDM-løsninger, er den primære forskjellen en filosofisk løsning. Det handler om hvem brukeren er. Sånn som jeg sa i begynnelsen av presentasjonen min, Alation, jeg tror, da vi ble grunnlagt, ble vi grunnlagt med et mål å gjøre det mulig for analytikere å produsere mer innsikt, å produsere dem raskere, for å være mer nøyaktige i innsikten som de produsere. Jeg tror ikke det noen gang har vært målet med en tradisjonell MDM-løsning. Disse løsningene har en tendens til å være rettet mot mennesker som trenger å produsere rapporter om hvilke data som er hentet til SCC eller internt for et annet slags revisjonsformål. Noen ganger kan det aktivere analytikere, men det er oftere at hvis det skal gjøre det mulig for en utøver i deres arbeid, er det mer sannsynlig å aktivere en dataarkitekt som en DBA.
Når du tenker på ting fra en analytikers ståsted, er det når du begynner å bygge et spørringsverktøy som et MDM-verktøy aldri ville gjort. Det er da du begynner å tenke på ytelse så vel som nøyaktighet, samt forstå hvilke data som knytter seg til forretningsbehovet mitt. Alle disse tingene er ting som slags spretter i tankene våre når vi designer verktøyet. Den går inn i søkealgoritmene våre, den går inn i utformingen av katalogsidene og muligheten til å bidra med kunnskap fra hele organisasjonen. Det går inn på at vi bygde spørringsverktøyet og at vi bygde katalogen direkte inn i det, så jeg tror det virkelig kommer av det. Hvilken bruker har du først i tankene?
Rebecca Jozwiak: Ok, bra. Det hjalp virkelig med å forklare det. som var døende for å få tak i arkivene fordi han måtte forlate, men han ville virkelig at spørsmålet hans skulle bli besvart. Han sa at det ble nevnt i begynnelsen at det er flere språk, men er SQL det eneste språket som brukes i Compose-komponenten?
David Crawford: Ja, det er sant. Og en av tingene som jeg har lagt merke til, da jeg på en måte har vært vitne til eksplosjonen av de forskjellige typene databaser, av dokumentdatabaser, av grafikkdatabaser, av viktige verdibutikker, er at de virkelig er kraftige for applikasjonsutvikling. De kan tjene spesielle behov der veldig bra, på bedre måter enn relasjonsdatabaser kan.
Men når du tar den med tilbake til dataanalyse, når du tar den tilbake til - når du vil gi den informasjonen til folk som skal gjøre ad hoc-rapportering eller ad hoc-graving i dataene, at de alltid kommer tilbake til en relasjon, i det minste, grensesnitt for menneskene. En del av det er bare fordi SQL er lingua franca for dataanalyse, så det betyr, for menneskene, det er også for verktøyene som integreres. Jeg tror dette er grunnen til at SQL på Hadoop er så populært og det er så mange forsøk på å løse det, fordi det på slutten av dagen er det folk vet. Det er sannsynligvis millioner av mennesker som vet hvordan de skal skrive SQL, og jeg vil ikke våge millioner som vet hvordan de skal skrive en Mongo-aggregasjonsrørledningssøket. Og at det er et standardspråk som brukes til integrasjon på et veldig bredt utvalg av plattformer. Så alt det er, vi blir sjelden bedt om å gå utenfor det fordi dette er grensesnittet som de fleste analytikere bruker, og det er et sted hvor vi fokuserte, spesielt i Compose, at vi fokuserte på å skrive SQL.
Jeg vil si datavitenskap er stedet der de satser utenfor mest, og at vi får sporadiske spørsmål om bruk av gris eller SAS. Dette er ting vi definitivt ikke håndterer i Compose, og som vi ønsker å fange opp i katalogen. Og jeg ser også R og Python. Vi har et par måter vi har laget grensesnitt som du kan bruke spørsmålene som er skrevet i Alation på innsiden av R- og Python-skript, så siden du ofte er dataforsker og jobber på skriptspråk, kildedata er i en relasjonsdatabase. Du starter med en SQL-spørring og deretter behandler du den videre og lager grafer inne i R og Python. Og vi har laget pakker som du kan importere til de skriptene som trekker spørsmålene eller spørringsresultatene fra Alation, slik at du kan ha en blandet arbeidsflyt der.
Rebecca Jozwiak: Ok, flott. Jeg vet at vi har løpt litt forbi toppen av timen, jeg skal bare stille ett eller to spørsmål til. Jeg vet at du snakket om alle de forskjellige systemene du kan koble til, men så langt som eksternt vert data og internt vertsdata, kan det sammen søkes i ditt enkelt synspunkt, i din ene plattform?
David Crawford: Visst. Det er noen måter å gjøre det på. Jeg mener, eksternt vert, kan jeg tenke meg, jeg prøver å tenke på nøyaktig hva det kan bety. Det kan bety en database som noen vert i AWS for deg. Det kan bety en offentlig datakilde fra data.gov. Vi kobler oss direkte til databaser ved å logge på akkurat som et annet program med, med en databasekonto, og det er slik vi trekker ut metadataene. Så hvis vi har en konto og har en nettverksport, kan vi komme til den. Og når vi ikke har disse tingene, har vi noe som kalles en virtuell datakilde, som lar deg i det vesentlige skyve dokumentasjon, enten det er automatisk, ved å skrive din egen kontakt, eller ved å fylle den ut ved å gjøre til og med som en CSV-opplasting, for å dokumentere dataene sammen med dine interne data. Dette blir plassert i søkemotoren. Det blir henvisbar inne i artikler og annen dokumentasjon og samtaler i systemet. Så det er slik vi håndterer når vi ikke direkte kan koble oss til et system.
Rebecca Jozwiak: Ok, det er fornuftig. Jeg skal bare skyte ut et spørsmål til deg. En deltaker er spør: "Hvordan skal innholdet i en datakatalog bli validert, bekreftet eller vedlikeholdt, når kildedata blir oppdatert, når kildedata blir endret, etc."
David Crawford: Ja, det er et spørsmål vi får mye, og jeg tror en av tingene som vi - en av våre filosofier, som sagt, ikke tror vi brukerne er ondsinnet. Vi antar at de prøver å bidra med den beste kunnskapen. De har ikke tenkt å komme inn og bevisst villede folk om dataene. Hvis det er et problem hos organisasjonen din, er kanskje Alation ikke det rette verktøyet for deg. Men hvis du antar gode intensjoner fra brukerne, så tenker vi på det som noe der oppdateringene kommer inn, og da er det vi vanligvis stiller som ansvarlig for hvert dataobjekt eller hver del av dataene. Og vi kan varsle de tillitsvalgte når endringer i metadataene gjøres, og de kan håndtere det på den måten. De ser at oppdateringer kommer inn, de validerer dem. Hvis de ikke har rett, kan de gå tilbake og endre dem og informere, og forhåpentligvis selv nå ut til brukeren som bidro med informasjonen og hjelpe dem å lære.
Så det er den viktigste måten vi tenker på å gjøre det på. Denne typen forslag fra mengden og ledelse av de tillitsvalgte, så vi har noen muligheter rundt det.
Rebecca Jozwiak: Ok, bra. Og hvis du bare kunne fortelle folk hvordan de best kan komme i gang med Alation, og hvor kan de gå spesifikt for å få mer info. Jeg vet at du delte det litt. Er det det beste stedet?
David Crawford: Alation.com/learnmore Jeg synes er en fin vei å gå. For å registrere deg for en demo har Alation.com-nettstedet mange gode ressurser, kundeoppgaver og nyheter om løsningen vår. Så jeg synes det er et flott sted å begynne. Du kan også sende e-post.
Rebecca Jozwiak: Ok, flott. Og jeg vet, deltagere, beklager hvis jeg ikke fikk tak i alle spørsmålene i dag, men hvis ikke, vil de bli videresendt til David eller salgsteamet hans eller noen på Alation, så de kan definitivt hjelpe med å svare på spørsmålene dine og hjelpe til med å forstå hva Alation gjør eller hva de gjør best.
Og med det, folkens, vil jeg gå videre og signere oss. Du kan alltid finne arkivene på InsideAnalysis.com. Du finner den også på Techopedia.com. De har en tendens til å oppdatere litt raskere, så absolutt sjekk det ut. Og så mye takk til David Crawford, Dez Blanchfield og Robin Boor i dag. Det har vært en flott webcast. Og med det skal jeg ta farvel. Takk, folkens. Ha det.
David Crawford: Takk.
