Hämtmat: Värd Rebecca Jozwiak diskuterar fördelarna med datakataloger med Dez Blanchfield, Robin Bloor och David Crawford.
Du måste registrera dig för den här händelsen för att se videon. Registrera dig för att se videon.
Rebecca Jozwiak: Mina damer och herrar, hej och välkommen till Hot Technologies 2016. Idag har vi fått: "The Power of Suggestion: How a Data Catalog Empower Analysts." Jag är din värd Rebecca Jozwiak och fyller i för vår vanliga värd Eric Kavanagh idag, medan han reser världen, så tack för att du gick med oss. Detta år är varmt, det är inte bara varmt i Texas där jag är, utan det är varmt överallt. Det finns en explosion av alla typer av ny teknik som kommer ut. Weve fick IoT, strömmande data, adoption av moln, Hadoop fortsätter att mogna och adopteras. Vi har automatisering, maskininlärning, och allt detta är naturligtvis understrykt av data. Och företagen blir mer och mer data som drivs av dagen. Och naturligtvis är poängen med det att leda till kunskap och upptäckt och, du vet, ta bättre beslut. Men för att verkligen få ut mesta möjliga värde från data måste det vara lätt att komma till. Om du håller den inlåst, eller begravd, eller i hjärnan för några få personer inom företaget, kommer det inte att göra mycket bra för företaget som helhet.
Och jag tänkte lite på datakatalogisering och tänkte naturligtvis på bibliotek, där för länge sedan det var dit du åkte om du behövde ta reda på något, om du behövde undersöka ett ämne eller leta upp lite information gick du till biblioteket , och naturligtvis gick du till kortkatalogen, eller den skitiga damen som arbetade där. Men det var också roligt att vandra runt, om du bara ville titta, och säker på att du kanske bara upptäcker något snyggt, kanske du får reda på några intressanta fakta som du inte visste, men om du verkligen behövde ta reda på något, och du visste vad du letade efter, du behövde kortkatalogen, och företagsekvivalenterna är naturligtvis en datakatalog, som kan hjälpa oss att lysa all information för våra användare att berika, upptäcka, dela, konsumera och verkligen hjälpa människor att få till data snabbare och enklare.
Så idag har vi fått Dez Blanchfield, vår egen datavetare, och vi har doktor Robin Bloor, vår egen chefanalytiker, vi har fått David Crawford från Alation, som kommer att prata om sitt företags datakatalogiseringshistoria, men först ska vi att leda med Dez. Dez, jag skickar bollen till dig och golvet är ditt.
Dez Blanchfield: Tack, tack för att du har mig idag. Det här är en fråga som jag är oerhört intresserad av, för nästan varje organisation jag stöter på i mitt dagliga arbete, hittar jag exakt samma fråga som vi talade mycket kort om i pre-show-skänket, och det är det de flesta organisationer som har varit verksamma i mer än några år har en mängd data begravda runt organisationen, olika format, och jag har faktiskt klienter som har datauppsättningar som går tillbaka till Lotus Notes, databaser som fortfarande körs i vissa fall som deras pseudointerneter, och de stöter på den här utmaningen att faktiskt hitta var deras data är, och hur man får tillgång till dem, vem ska ge tillgång till dem, när man ska ge åtkomst till dem och hur man bara katalog, och hur man får den till en plats där alla kan: A) vara medvetna om vad som finns där och vad som finns i det, och B), hur man får tillgång till det och använder det. Och en av de största utmaningarna är naturligtvis att hitta den, den andra stora utmaningen är att veta vad som finns där och hur man får åtkomst till det.
Jag kanske väl vet att jag har massor av databaser, men jag vet faktiskt inte vad som finns där eller hur jag kan ta reda på vad som finns där, och så alltid som vi upptäcker nu i pre-show-data, du tenderar att gå runt kontoret och ställa frågor, och skrika över de kubiska väggarna och försöka ta reda på, ofta är min erfarenhet, du kanske till och med hittar att du vandrar till receptionen, receptionen och frågar om någon vet vem du " kommer att gå och prata med. Ganska ofta är det inte alltid IT-folket eftersom de inte känner till datauppsättningen eftersom någon just har skapat den, och det kan vara något enkelt som en - ganska ofta hittar vi ett projekt av något slag som står upp i IT-miljö och projektledaren använde ett kalkylblad med alla saker, och det har fått en enorm mängd värdefull information kring tillgångar och nackdelar och namn, och såvida du inte känner till det projektet och du känner den personen, kan du bara inte hitta den informationen. Det är bara inte tillgängligt, och du måste ta tag i den ursprungliga filen.
Det finns en fras som har blivit omslagen med avseende på data och jag håller inte nödvändigtvis med om det, men jag tror att det är en söt liten kast och det är att en viss mängd människor tycker att data är den nya oljan, och jag är säker på att vi kommer att täcka det också i någon aspekt, senare i dag. Men vad jag har lagt märke till, verkligen som en del av den omvandlingen, är att organisationer av företag som har lärt sig värdera sina uppgifter har fått betydande fördelar jämfört med sina konkurrenter.
Det fanns en intressant uppsats av IBM, för cirka fem eller sex år sedan, och de undersökte cirka 4 000 företag här i Australien, och de tog all information, alla prestationsdata, alla finansdata och satte dem samman i en kokande kastrull och sedan skickade den till Australian School of Economics, och de startade faktiskt en gemensam trend här, och det var att företag som utnyttjade teknik alltid fick en sådan konkurrensfördel gentemot sina kamrater och konkurrenter i sig att deras konkurrenter nästan aldrig hamnar, och jag tror det är väldigt fallet nu med data som vi har sett vad folk kallar en digital transformation där organisationer som tydligt har kommit fram till hur de hittar data de har, att göra den informationen tillgänglig och göra den tillgänglig i en mycket lätt förbrukningsvara mode för organisationen, utan att nödvändigtvis alltid veta varför organisationen kan behöva det och få betydande fördelar jämfört med konkurrenter.
Jag har ett par exempel på den här bilden, som du kan se. Min ena linje är att den storskaliga störningen i nästan alla industrisektorer enligt min åsikt drivs av data, och om de nuvarande trenderna är något att gå, är min åsikt att vi bara egentligen bara har fått började eftersom när de långvariga märkena äntligen vaknar upp vad det här betyder och kommer in i spelet kommer de att delta i spelet i grossistledet. När sorts stora detaljhandlare som har berg med data börjar tillämpa en historisk analys av uppgifterna, om de till och med vet att det existerar, kommer några av onlinespelarna att få lite av ett wakeup-samtal.
Men med många av de flesta av dessa märken, menar jag att vi har Uber som är världens största taxibolag. De äger inga taxibilar, så vad är det som gör dem magiska, vad är deras data? Airbnb, den största leverantören av boende, har vi WeChat, världens största telefonföretag, men de har ingen faktisk infrastruktur och inga telefoner, inga telefonlinjer. Alibaba, den största återförsäljaren på planeten, men de äger inte någon av inventarierna. , det största medieföretaget i ordet. Jag tror att de vid den sista räkningen hade 1,4 miljarder aktiva datanvändare nu, vilket är ett otroligt antal. Det är inte någonstans i närheten - jag tror att någon hävdade att en fjärdedel av planeten faktiskt finns där varje dag, och ändå här är en innehållsleverantör som faktiskt inte skapar innehållet, all information som de tjänar skapas inte av dem, den är skapad av deras prenumeranter, och vi känner alla till den här modellen.
SocietyOne, som du kanske eller inte har hört talas om, det är ett lokalt varumärke, jag tror att i ett par länder är det en bank som faktiskt gör peer-to-peer-utlåning, så med andra ord har den inga pengar. Allt det gör är att det hanterar transaktionerna och uppgifterna sitter under det. Netflix, vi är alla väldigt, mycket bekanta med det. Det finns en intressant enfodring här. När Netflix lagligen kunde användas i Australien, när det officiellt tillkännagav, behövde du inte använda ett VPN för att komma till det, många människor runt om i världen tenderar att - om du inte kan komma till det i ditt lokala område - när Netfix lanserades i Australien, det ökade den internationella bandbredden på våra internetlänkar med 40 procent, så det nästan fördubblade internetanvändningen i Australien över natten, med bara en applikation, en moln-värd applikation som inte gör annat än att spela med data. Det är bara en överväldigande statistik.
Och naturligtvis är vi alla bekanta med Apple och Google, men det här är de största mjukvaruföretagen på planeten, men de skriver faktiskt inte apparna. Vad är det som är konsekvent med alla dessa organisationer? Det är data, och de kom inte dit för att de inte visste var deras data var, och de visste inte hur de skulle katalogisera det.
Vad vi hittar nu är att det finns denna helt nya tillgångsklass som kallas data, och företag vaknar upp för det. Men de har inte alltid verktygen och kunskapen och varför man kan kartlägga all den informationen, att katalogisera all den informationen och göra den tillgänglig, men vi har funnit att företag med nästan inga fysiska tillgångar har fått högt marknadsvärde på rekordtid via denna nya datatillgångsklass. Som jag sa, några av de gamla spelarna vaknar nu upp för detta och säkert kommer ut det.
Jag är ett stort fan av att ta folk på en liten bit av en resa, så under de arton hundra, sena arton hundra, och du kommer att vara mer än bekant med detta på den amerikanska marknaden, visade det sig att för att få en folkräkning varje år eller så tror jag att de körde dem vart tionde år vid den punkten, men om du ska göra en folkräkning varje år kan det ta upp till åtta eller nio år att faktiskt göra dataanalysen. Det visade sig att den datauppsättningen sedan satt kvar i rutorna på platser i papper, och nästan ingen kunde hitta den. De fortsatte bara att pumpa ut dessa rapporter, men de faktiska uppgifterna var väldigt svåra att få till, vi har en liknande situation med en annan betydelsefull stund, runt 1940-talet, med andra världskriget, och det här är Bletchley Park Bombe stavade BOMBE , och det var ett massivt analytiskt verktyg som skulle gå igenom små datauppsättningar och hitta signaler i det och användas för att hjälpa till att knäcka koder genom Enigma.
Det här igen, var i huvudsak en enhet designad, inte mycket för att katalogisera, men för att tagga och kartlägga data, och göra det möjligt att ta mönster och hitta det i datauppsättningarna, i detta fall bryta koder, hitta nycklar och fraser och hitta dem regelbundet i datauppsättningarna, och så har vi genomgått denna resa att hitta saker i data och leda mot katalogisering av data.
Och sedan kom de här sakerna, dessa massiva lågkostnadsställningar med maskiner, precis utanför hyllmaskinerna. Och vi gjorde några mycket intressanta saker, och en av de saker vi gjorde med dem är att vi byggde väldigt billiga kluster som kunde börja indexera planeten, och mycket känt dessa stora varumärken som har kommit och gått, men förmodligen Googles det vanligaste hemmet märke som vi alla har hört talas om - det har blivit ett verkligt verb, och du vet att du lyckas när ditt märke blir ett verb. Men vad Google lärde oss, utan att inse det, eventuellt i affärsvärlden, är att de kunde indexera hela planeten till en viss nivå och katalogisera data som fanns runt om i världen och göra den tillgänglig på en mycket enkel, bekväm form i en liten liten en-formel, en webbsida med nästan ingenting på den, och du skriver in din fråga, den går och hittar den för att de redan hade genomsökt planeten, indexerat den och gjort den lättillgänglig.
Och vad vi märkte var: ”Tänk på, vi gör inte detta i organisationer - varför är det? Varför är det att vi har en organisation som kan kartlägga hela planeten och indexera den, krypa och indexera den och göra den tillgänglig, vi kan söka efter den och sedan klicka på saken för att hitta den, hur kommer vi har det inte gjort det internt? ”Så det finns massor av de här små racken med maskiner runt om i världen nu som gör det för intranät och hittar saker, men de kommer fortfarande bara att ta hand om idén att gå utöver den traditionella webbsidan, eller en filserver.
Istället för att nu gå in på nästa generation av datakatalog på många sätt, är det inte riktigt en lämplig metod för upptäckt och katalogisering av data via post-it-anteckningar och vattenkylare konversationer längre, och jag tror inte att det någonsin var . Vi kan inte längre leda den hela utmaningen till människor som bara skickar anteckningar och lägger ut anteckningar och pratar om det. Vi är väl och verkligen bortom området nu där den här nästa gen-strategin för datakatalogisering har kommit och gått. Vi måste få våra armar runt det. Om detta var en enkel fråga, skulle vi redan ha löst det på många sätt tidigare, men jag tror att det inte är en enkel fråga, bara att indexera och ringa uppgifterna är bara en del av det, veta vad som finns i data och bygga metadata runt vad vi upptäcker och sedan göra det tillgängligt i en lätt, förbrukningsbar form, särskilt för självbetjäning och analys. Det är fortfarande ett problem att lösas, men många delar av pusslet på fem år är väl och verkligen löst och tillgängligt.
Som vi vet är människors katalogisering av data ett recept för misslyckande eftersom mänskliga misstag är en av de största mardrömmar vi hanterar vid databehandling, och jag pratar regelbundet om detta ämne där människor enligt min åsikt förmodligen är den största mardrömmen vi hanterar i big data och analys, att ständigt behöva fixa saker som de gör, till och med till enkla saker som datum och fält, människor som sätter det i fel format.
Men som jag sa, vi har sett internetsökmotorer indexera världen varje dag, så nu gör vi det till idén att det kan göras på affärsdatasyster i upptäcktsprocessen, och verktyg och system är nu lätt tillgängligt som du ska lära dig idag. Så tricket, verkligen enligt min åsikt, är att välja rätt verktyg, de bästa verktygen för jobbet. Och mer lämpligt ovanpå det, att hitta rätt del av det för att hjälpa dig komma igång denna väg. Och jag tror att vi kommer att höra om det idag, men innan vi gör det kommer jag att överföra till min college, Robin Bloor och höra hans uppfattning om ämnet. Robin, kan jag överföra till dig?
Robin Bloor: Ja, det kan du verkligen. Låter oss se om detta fungerar, oh ja det gör det. Okej, jag kommer från en annan riktning än Dez egentligen, men jag hamnar på samma plats. Det här handlar om att ansluta till data, så jag tänkte bara att jag skulle gå igenom verkligheten att ansluta till data, punkt för punkt verkligen.
Det finns ett faktum att data är mer fragmenterade än de någonsin varit. Volymen av data växer fenomenalt, men i själva verket växer de olika datakällorna också otroligt, och därför blir data allt mer fragmenterade hela tiden. Men på grund av analysapplikationer i synnerhet - men det är inte de enda applikationerna - har vi en riktigt bra anledning att ansluta till all denna data, så vi sitter fast på en svår plats, vi sitter fast i en värld av fragmenterade data, och det finns möjligheter i uppgifterna som Dez kallade det, den nya oljan.
Om data, ja, det brukade leva på en snurrdisk, antingen i filsystem eller databaser. Nu lever det i en mycket mer varierad miljö, den lever i filsystem men den lever också i Hadoop-instanser idag, eller till och med Spark-instanser. Den lever i flera databaser. För inte så länge sedan standardiserade vi någon relationell databas, du vet att det gick ut genom fönstret under de senaste fem åren, för det finns ett behov av dokumentdatabaser och det finns ett behov av grafdatabaser, så du vet, spelet har ändrats. Så den levde på snurrdisken, men den lever nu på SSD. Den senaste mängden SSD - definitivt den senaste SSD-enheten kommer från Samsung - tjugo gigabyte, vilket är enormt. Nu lever det i minnet, i den meningen att den främsta kopian av data kan finnas i minnet, snarare än på disk, brukade vi inte bygga system som det; det gör vi nu. Och det lever i molnet. Vilket innebär att det kan leva i någon av dessa saker, i molnet, du behöver inte nödvändigtvis veta var det är i ett moln, du kommer bara att ha sin adress.
Bara för att ramma hem poängen, Hadoop hittills har misslyckats som en utdragbar datalager. Vi hade hoppats att det skulle bli en utvidgbar, utskalad datalager, och det skulle bara bli ett filsystem för allt, och det skulle - regnbågar skulle dyka upp på himlen, i princip, och enhörningar skulle dansa runt, och inget av det hände. Vilket innebär att vi slutar med ett problem med datatransport, och det är inte nödvändigtvis datatransport ibland, men det är också svårt. Data har verkligen allvar nuförtiden, när du väl har kommit in i flera terabyte med data, plockat upp den och kastat den runt, typ av orsaker att latenser visas i ditt nätverk eller att dyka upp på olika platser. Om du vill transportera data runt är timing en faktor. Det finns nästan alltid, numera, några gränser för hur mycket tid du har att få en sak, en data från en plats till en annan plats. Det brukade vara det vi brukade tänka på som buntfönster, när maskinen var lite tom, och oavsett hur mycket data du hade, kunde du bara slänga den och allt skulle fungera. Det är väl borta, vi lever i en mycket mer realtidsvärld. Därför är timing en faktor. Så snart du vill flytta data, så om uppgifterna har allvar, kan du förmodligen inte flytta den.
Datahantering är en faktor i den meningen att du faktiskt måste hantera alla dessa uppgifter, du får inte det gratis, och replikering kan vara nödvändig för att faktiskt få uppgifterna att göra det jobb det behöver göra, eftersom det kan inte vara var du än har sagt det. Det kanske inte har tillräckliga resurser för att kunna utföra normal behandling av uppgifterna. Så data replikeras och data replikeras mer än du skulle föreställa dig. Jag tror att någon sa för mig för länge sedan att den genomsnittliga datadelen replikeras minst två och en halv gånger. ESBs eller Kafka presenterar ett alternativ för dataflöde, men numera kräver det arkitektur. Nuförtiden måste du verkligen tänka på ett eller annat sätt, vad det faktiskt betyder att kasta data runt. Därför är det vanligtvis att föredra att få tillgång till data där det är, så länge du naturligtvis kan få den prestanda du behöver när du faktiskt söker efter data och det beror på con. Så det är en svår situation, i alla fall. När det gäller dataförfrågningar brukade vi kunna tänka i termer av SQL, vi har verkligen kommit upp nu, du vet, olika former av frågor, SQL ja, men intilliggande, även diagramfrågor, Spark är bara ett exempel på att göra graf , eftersom vi också behöver göra sökningar, mer än vi någonsin gjort, också regex-typ av sökningar, vilket är riktigt komplicerade sökningar efter mönster och äkta mönstermatchning, alla dessa saker bubblar faktiskt av. Och alla av dem är användbara eftersom de får dig det du letar efter, eller så kan de få det du letar efter.
Frågor nu dagar spänner över flera data, så det gjorde det inte alltid, och ofta är prestandan skrämmande om du gör det. Så det beror på omständigheterna, men människor förväntar sig att kunna fråga data från flera datakällor, så dataförbund av en eller annan typ blir mer och mer aktuell. Datavirtualisering, vilket är ett annat sätt att göra det, beroende på prestanda, är också mycket vanligt. Datafrågor är faktiskt en del av en process, inte hela processen. Det är bara värt att påpeka att om du faktiskt tittar på analysprestanda kan själva analysen ta väldigt mycket längre tid än datainsamlingen, eftersom det beror på omständigheterna, men datafrågor är en absolut nödvändighet om du vill göra något typ av analys på flera datakällor, och det bara, du måste verkligen ha funktioner som sträcker sig.
Så om kataloger.Kataloger finns av en anledning, åtminstone säger vi att, du vet, dess, vi har kataloger, och vi har scheman i databaser, och vi har varje katalog och vi har vart du än går du hittar en plats och sedan kommer du faktiskt upptäcker att det finns någon form av katalog, och den enhetliga globala katalogen är så uppenbarligen bra idé. Men väldigt få företag har en sådan sak. Jag kommer ihåg, redan under två tusen - året två tusen panik - jag kommer ihåg att kommunister inte ens kunde fastställa hur många körbara de hade, oavsett hur många olika datalager de hade, och det är förmodligen fallet nu, du vet, att de flesta företag inte aktivt vet i global mening, vilken information de har. Men det blir uppenbart alltmer nödvändigt att faktiskt ha en global katalog, eller åtminstone ha en global bild av vad som händer på grund av tillväxten av datakällor och den fortsatta tillväxten av applikationer, och det är särskilt nödvändigt för analys, eftersom du också på ett sätt, och det finns andra problem här som avstamning och problem med uppgifterna, och det är nödvändigt för säkerhet, många aspekter av datastyrningen, om du verkligen inte vet vilka data du har, idén att du kommer att styra det är bara absurd. Därför att all information katalogiseras på något sätt är bara ett faktum. Frågan är om katalogen är sammanhängande och vad du kan göra med den. Så jag ska gå tillbaka till Rebecca.
Rebecca Jozwiak: Okej, tack Robin. Därefter har vi fått David Crawford från Alation, David. Jag ska gå vidare och skicka bollen till dig, så kan du ta bort den.
David Crawford: Tack så mycket. Jag uppskattar verkligen att ni har mig på den här showen. Jag tror att jag kommer att komma igång, så jag tror att min roll här är att ta en del av den teorin och se hur den faktiskt tillämpas, och de resultat som vi kan driva på riktiga kunder och så kan du se några på bilden, jag vill prata om vilka resultat vi kan se i analytiska eventuella förbättringar. Så för att motivera diskussionen kommer vi att prata om hur de kom dit. Så jag är tur att få jobba ganska nära med många riktigt smarta människor, dessa kunder, och jag vill bara påpeka några som har kunnat mäta, och prata om hur en datakatalog har påverkat deras analytiker arbetsflöde. Och bara för att stanna i framkant, tror jag att en av de saker som vi ser förändras, med datakataloger verser tidigare medierade lösningar och ett av de sätt som relationer verkligen tänker på de lösningar som vi sätter ihop, är att börja från analytikerna och arbeta bakåt. För att säga, låt oss göra detta om att möjliggöra analytikernas produktivitet. Till skillnad från bara efterlevnad, eller i motsats till att bara ha en inventering, gör vi ett verktyg som gör analytiker mer produktiva.
Så när jag pratar med en datavetare på finansföretaget Square finns det en kille, Nick, som berättade om hur hans, han brukade ta flera timmar för att hitta rätt datauppsättning för att starta en rapport, nu kan han gör det på några sekunder med sökning efter marknadsandel, vi pratade med deras CTO som drog sina analytiker som använde Square, ursäkta mig, använde Alation, för att ta reda på vad deras, vilka fördelar de såg, och de rapporterade en 50 procent ökad produktivitet, och att den, en av världens bästa återförsäljare, eBay, har över tusen personer som gör SQL-analys regelbundet, och jag arbetar ganska nära med Deb Says där borta, vem är projektet chef i deras dataverktygsteam, och hon fann att när frågeställningar antar Alation, antar en katalog, ser de dubbelt så snabbt som de skriver nya frågor mot databasen.
Så det här är verkliga resultat, det här är människor som faktiskt tillämpar katalogen i sin organisation, och jag vill ta dig igenom vad som krävs för att du ska kunna skapa. Hur en katalog etableras i ett företag, och kanske det viktigaste att säga, är att mycket av det händer automatiskt, så Dez pratade om system, lära sig om system och det är exakt vad en modern datakatalog gör. Så de installerar Alation i sitt datacenter och sedan ansluter de det till olika källor till metadata i sin datamiljö. Jag kommer att fokusera lite på databaserna och BI-verktygen - från båda dessa kommer vi att ta ut tekniska metadata, i princip om vad som finns. Rätt, så vilka tabeller? Vilka rapporter? Vad är rapportdefinitionerna? Så de extraherar de tekniska metadata, och en katalogsida skapas automatiskt för varje objekt inuti dessa system, och sedan extraherar och lagrar de också ovanpå de tekniska metadata, de lager ovanpå användningsdata. Det görs främst genom att läsa frågeloggar från databasen, och det här är en riktigt intressant informationskälla. Så, när en analytiker skriver en fråga, när ett rapporteringsverktyg, oavsett om det är hemodlat eller från hyllan, om ett rapporteringsverktyg kör en fråga för att uppdatera instrumentpanelen, när en applikation kör en fråga för att infoga data för att fungera på en datauppsättning - alla dessa saker fångas i databasfrågorna. Oavsett om du har en katalog eller inte, fångas de i frågeloggen med databasen. Vad en datakatalog kan göra, och särskilt vad Alations-katalogen kan göra, är att läsa de loggarna, ställa frågorna inuti dem och skapa en riktigt intressant användningsgraf baserad på dessa loggar, och vi tar det i spel för att informera framtida användare av data om hur tidigare användare av data har använt den.
Så vi samlar all den kunskapen i en katalog, och bara för att göra det här verkligt, det är de integrationer som redan är utplacerade hos kunder, så vi har sett Oracle, Teradata, Redshift, Vertica och en massa andra relationella databaser. I Hadoop-världen finns det en rad SQL på Hadoop, en slags relationella, meta-butiker ovanpå Hadoop-filsystemet, Impala, Tez, Presto och Hive, vi har också sett framgång med moln Hadoop privata leverantörer som Altiscale, och vi har också kunnat ansluta till Tableau-servrar, MicroStrategy-servrar och indexera instrumentpanelerna där, såväl som integrationer med datavetenskapliga kartverktyg som Plotly.
Så vi ansluter till alla dessa system, vi har anslutit dessa system till kunder, vi har dragit in de tekniska metadata, vi har dragit in användningsdata, och vi sorterar automatiskt datakatalogen, men på det sättet centralisera kunskapen, men bara centralisera saker i en datakatalog, ger inte i sig de riktigt underbara produktivitetsökningar som vi pratade om med eBay, Square och marknadsandel. För att göra det måste vi faktiskt ändra sättet vi funderar på att leverera kunskap till analytiker. En av frågorna som de ställer för att förbereda sig för detta var "Hur påverkar katalogen faktiskt en analytikers arbetsflöde?"
Det är vad vi tillbringar hela dagen med att tänka på, och för att prata om denna tänkandeförändring, om en push verses en pull-modell, ville jag göra en snabb analogi till hur världen var innan och efter att ha läst på en Kindle. Så det är bara en upplevelse som några av er kan ha, när du läser en fysisk bok, du stöter på ett ord, du är inte säker på att du känner ordets definition super bra, kan du kanske gissa det från con, inte så troligt att du ska gå upp från soffan, gå till din bokhylla, hitta din ordbok, damma bort den och vända till rätt plats i den alfabetiska listan med ord för att se till att, ja du hade den definitionen precis rätt, och du vet nyanserna av det. Så det händer inte riktigt. Så du köper en Kindle-app och du börjar läsa böcker där, och du ser ett ord du inte är helt säker på och du rör vid ordet. Helt plötsligt, precis på samma skärm, är ordboksdefinitionen av ordet, med alla dess nyanser, olika exempel på användningar, och du sveper lite, och du får en Wikipedia-artikel om det ämnet, du sveper igen, du får ett översättningsverktyg som kan översätta det till andra språk eller från andra språk, och plötsligt är din kunskap om språket så mycket rikare, och det händer bara ett häpnadsväckande antal gånger jämfört med när du var tvungen att gå och dra den resursen själv.
Och så vad jag kommer att argumentera är att arbetsflödet för en analytiker och hur en analytiker kommer att hantera datadokumentation faktiskt är mycket likt hur en läsare kommer att interagera med ordboken, vare sig den är fysisk, eller om Kindle, och så vad vi, på det sättet som vi verkligen såg detta produktivitetsökning, inte spilla katalogen utan ansluter den till arbetsflödet för analytikern, och så, de har bett mig att göra en demo här, och jag vill att göra det i fokus för denna presentation. Men jag vill bara ställa in con för demo. När vi funderar på att driva datakunskapen till användarna när de behöver den, tror vi att rätt plats att göra det, platsen där de tillbringar sin tid och där de gör analysen, är ett SQL-frågaverktyg. En plats där du skriver och kör SQL-frågor. Och så byggde vi ett, och vi byggde det, och det som verkligen skiljer sig åt det från andra frågaverktyg är dess djupa integration med datakatalogen.
Så vårt frågaverktyg kallas Alation Compose. Det är ett webbaserat frågaverktyg och jag visar det åt dig om en sekund. Ett webbaserat frågaverktyg som fungerar över alla databasloggorna som du såg på föregående bild. Vad jag ska försöka demonstrera särskilt är hur kataloginformationen kommer till användare. Och det gör det på den här typen av tre olika sätt. Det gör det genom ingripanden, och det är där någon som en datastyrare, eller en datatillsynsmann, eller en slags administratör på något sätt, eller en chef, kan säga, ”Jag vill sortera ett interject med en anteckning eller en varning i arbetsflödet och se till att det levereras till användare vid rätt tidpunkt. ”Så det är ett ingripande och väl visar det.
Smarta förslag är ett sätt där verktyget använder all sin samlade kunskap om katalogen för att föreslå objekt och delar av en fråga när du skriver det. Det viktigaste att veta där är att det verkligen drar nytta av frågeloggen för att göra det, för att föreslå saker baserade på användning och även hitta även delar av frågor som har skrivits tidigare. Och visa det.
Och förhandsvisar sedan. Förhandsgranskningar är, när du skriver in namnet på ett objekt, vi visar dig allt som katalogen vet, eller åtminstone de mest relevanta saker som katalogen vet om det objektet. Så prover av data, som hade använt den tidigare, det logiska namnet och beskrivningen av det objektet, kommer allt upp till dig medan du skriver det utan att behöva gå och be om det.
Så utan att prata mer kommer jag till demo och jag väntar bara på att den ska dyka upp. Vad jag ska visa dig här är frågaverktyget. Det är ett dedikerat SQL-skrivgränssnitt. Det är ett separat gränssnitt från katalogen, i en viss mening. Dez och Robin pratade om katalogen, och jag hoppade lite över kataloggränssnittet direkt till hur det kom direkt in för att betjäna arbetsflödet.
Jag visar bara här en plats där jag kan skriva SQL, och längst ner ser du att vi sorts har lite information som visas om de objekt som refererade till. Så jag ska bara börja skriva en fråga och jag ska sluta när jag kommer till ett av dessa ingripanden. Så jag skriver "välj", och jag vill ha året. Jag vill ha namnet. Och jag ska leta upp lite lönedata. Så detta är en utbildningsuppsättning. Den har information om institutioner för högre utbildning, och jag tittar på den genomsnittliga fakultetslönen i en av dessa tabeller.
Så jag har faktiskt skrivit ordet "lön." Det är inte exakt i kolumnens namn på det sättet. Vi använder både logiska metadata och fysiska metadata för att göra förslag. Och vad jag vill påpeka här är denna gula ruta som visas här. Det står att det finns en varning i den här kolumnen. Jag letade inte efter det, jag tog inte en klass om hur man använder dessa data korrekt. Det kom till mig, och det råkar vara en varning om ett sekretessavtal som har att göra med dessa uppgifter. Så det finns några regler för avslöjande. Om jag ska fråga dessa uppgifter, jag ska ta data ur denna tabell, bör jag vara försiktig med hur jag avslöjar det. Så du har en styrelsepolitik här. Det finns några utmaningar för efterlevnad som gör det så mycket lättare att följa denna policy när jag vet om det vid den tiden jag tittar på uppgifterna.
Så jag har fått det till mig, och sedan ska jag också titta på undervisning. Och här ser vi förhandsvisningarna komma in. I denna undervisningskolumn ser jag - det finns en undervisningskolumn på institutionstabellen, och jag ser en profil av det. Alation går och drar provdata från tabellerna, och i det här fallet visar det mig något som är ganska intressant. Det visar mig fördelningen av värdena och visar mig att nollvärdet dykte upp 45 gånger i provet och mer än något annat värde. Så jag har fått en känsla av att vi kanske saknar data.
Om jag är en avancerad analytiker, kan det vara en del av mitt arbetsflöde redan. Särskilt om jag är särskilt noggrann, där jag skulle göra en massa profilfrågor i förväg. När jag närmar mig en ny data, tänker jag alltid på vad vår datatäckning är. Men om jag är ny för dataanalys, om jag är ny i den här datauppsättningen, kan jag anta att om det finns en kolumn, så fylls den hela tiden. Eller jag kan anta att om det inte är fyllt i, det inte är noll, dess noll eller något liknande. Men i det här fallet har vi många nollor, och om jag gjorde ett genomsnitt skulle de förmodligen vara fel, om jag bara antog att dessa nollor faktiskt var noll istället för saknade data.
Men Alation, genom att föra den här förhandsgranskningen till ditt arbetsflöde, ber du dig att ta en titt på denna information och ger till och med en slags nybörjare analytiker en chans att se att det finns något att märka här om dessa data. Så vi har den förhandsgranskningen.
Nästa sak som jag ska göra är att jag ska försöka ta reda på vilka tabeller du får informationen från. Så här ser vi de smarta förslagen. Det har pågått hela tiden, men i synnerhet här har jag inte ens skrivit något annat än att det kommer att föreslå för mig vilka tabeller jag kanske vill använda för den här frågan. Och det viktigaste att veta om detta är att det drar nytta av användningsstatistiken. Så i en miljö som till exempel eBay, där du har hundratusentals bord i en enda databas, att ha ett verktyg som kan drabbas av vete och använda användningsstatistiken, är det verkligen viktigt för att göra dessa förslag värda något.
Så det kommer att föreslå denna tabell. När jag tittar på förhandsgranskningen markerar vi faktiskt tre av de kolumner som jag redan har nämnt i min fråga. Så jag vet att det har tre, men det har inte namnet. Jag måste få namnet, så jag kommer att gå med. När jag går med, nu har jag igen dessa förhandsgranskningar som hjälper mig hitta, var är tabellen med namnet. Så jag ser att den här har ett snyggt formaterat, typ av korrekt kapitaliserade namn. Det verkar ha en rad med ett namn för varje institution, så jag kommer att ta tag i det, och nu behöver jag ett anslutningsvillkor.
Och så, här som Alation gör är att återigen titta tillbaka på frågloggarna, se tidigare gånger att dessa två tabeller har gått samman och föreslå olika sätt att gå med i dem. Återigen, det finns viss ingripande. Om jag tittar på ett av dessa, fick det en varning som visar mig att detta bara ska användas för sammanställd analys. Det kommer förmodligen att producera fel sak om du försöker göra något genom institutionen efter institution. Medan denna, med OPE-ID, godkänns som det rätta sättet att gå med i dessa två tabeller om du vill ha data på universitetsnivå. Så jag gör det, och det är en kort fråga, men jag har skrivit min fråga utan att nödvändigtvis ha någon inblick i vad uppgifterna är. Jag har faktiskt aldrig tittat på ett ER-diagram över denna datauppsättning, men jag vet ganska mycket om dessa uppgifter redan för att relevant information kommer till mig.
Så det är typ av de tre sätten som en katalog, genom ett integrerat frågaverktyg, kan direkt påverka arbetsflödet när du skriver frågor. Men en av de andra fördelarna med att ha ett frågaverktyg integrerat med en katalog är att när jag är klar med min fråga och jag sparar den kan jag sätta en titel som ”Institutionen undervisning och fakultetslön”, och sedan har jag en knapp här som låter mig bara publicera den i katalogen. Det blir väldigt lätt för mig att mata tillbaka detta. Även om jag inte publicerar det, blir det fångat som en del av frågeloggen, men när jag publicerar det, blir det faktiskt en del av det sätt att den centraliserade platsen där all datakunskap lever.
Så om jag klickar på Sök efter alla frågor i Alation, kommer jag att tas - och här ser du lite mer av kataloggränssnittet - Jag kommer till en dedikerad frågesökning som visar mig ett sätt att hitta frågor i hela organisationen. Och du ser att min nyligen publicerade fråga är överst. Och vissa kanske märker här på när vi fångar frågorna, vi fångar också författarna, och vi skapar ett slags förhållande mellan mig som författare och dessa dataobjekt som jag nu vet något om. Och jag är etablerad som expert på denna fråga och på dessa dataobjekt. Det är verkligen bra när människor behöver lära sig om data, då kan de hitta rätt person att lära sig om. Och om jag faktiskt är ny med data, vare sig jag är en avancerad analytiker - som avancerad analytiker, kanske jag tittar på det här och ser ett gäng exempel som skulle komma igång med en ny datamängd. Som någon som kanske inte känner mig superkunnig med SQL kan jag hitta förberedda frågor som är rapporter som jag kan dra nytta av.
Här är en av Phil Mazanett om median SAT-poäng. Klicka på detta, så får jag en slags katalogsida för själva frågan. Det talar om en artikel som har skrivits som refererar till den här frågan, så det finns en del dokumentation för mig att läsa om jag vill lära mig att använda den. Och jag kan öppna det i frågaverktyget genom att klicka på Skapa-knappen och jag kan bara köra det själv här utan att ens redigera det. Och faktiskt får du se lite av våra lätta rapporteringsfunktioner, där du, när du skriver en fråga, kan släppa in en mallvariabel som den här och det skapar ett enkelt sätt att skapa ett formulär för att utföra en fråga baserad på en ett par parametrar.
Så det är vad jag har för demon. Jag ska växla tillbaka till bilderna.Bara för en typ av sammanfattning visade vi hur en administratör, en databehandlare, kan ingripa genom att placera varningar på objekt som dyker upp i frågaverktyget, hur Alation använder sin kunskap om användningen av dataobjekt för att göra smarta förslag, hur det ger i profilering och andra tips för att förbättra arbetsflöden för analytiker när de rör vid specifika objekt, och hur alla den typen av feeds återgår till katalogen när nya frågor skrivs.
Självklart är jag en talesman på företagets vägnar. Jag ska säga fina saker om datakataloger. Om du vill höra direkt från en av våra kunder, driver Kristie Allen på Safeway ett team av analytiker och har en riktigt cool historia om en tid då hon verkligen behövde slå klockan för att leverera ett marknadsföringsexperiment och hur hennes hela team använde Alation för att samarbeta och vända riktigt snabbt på det projektet. Så du kan följa den här bit.ly-länken för att kolla in den berättelsen, eller om du vill höra lite om hur Alation kan föra in en datakatalog till din organisation, kan vi gärna skapa en personlig demo. Tack så mycket.
Rebecca Jozwiak: Tack så mycket, David. Jag är säker på att Dez och Robin har några frågor innan jag vänder mig till publikens frågor och svar. Dez, vill du gå först?
Dez Blanchfield: Absolut. Jag älskar idén med det här konceptet med publicerade frågor och kopplar det tillbaka till källan till författaren. Jag har varit en länge mästare för denna idé om en egen app-butik och jag tycker att detta är en riktigt bra grund att bygga vidare på.
Jag kom till att få lite inblick i några av de organisationer som du ser att göra detta, och några av de framgångshistorier som de kan ha haft med hela denna resa för att inte bara utnyttja ditt verktyg och plattform för att upptäcka data, utan också sedan omvandla sina interna kulturella och beteendemässiga egenskaper. Nu med den här typen av egen app-butik där du bara laddar ner, konceptet där de inte bara kan hitta det, utan de faktiskt kan börja utveckla små samhällen med behållarna av den kunskapen.
David Crawford: Ja, jag tror att vi har blivit förvånade. Vi tror på värdet av att dela frågor, både från mitt förflutna som produktchef i Adtech och från alla kunder som vi har pratat med, men jag har fortfarande varit förvånad över hur ofta det är en av de allra första saker som kunderna pratar om som värde att de kommer ut ur Alation.
Jag gjorde en användartest av frågaverktyget hos en av våra kunder som heter Invoice2go, och de hade en produktansvarig som var relativt ny, och de sa - han sa faktiskt till mig, opåverkad under användartestet, ”Jag skulle faktiskt inte skriva SQL överhuvudtaget förutom att det är enkelt av Alation. ”Och naturligtvis, som premiärminister, går jag sånt,” Vad menar du, hur gjorde vi det? ”Och han sa:” Tja, det är egentligen bara för att jag kan logga in och jag kan se alla dessa befintliga frågor. ”Att börja med en tom skiffer med SQL är en oerhört svår sak att göra, men att ändra en befintlig fråga där du kan se resultatet som läggs ut och du kan säga," Åh , Jag behöver bara den här extra kolumnen, "eller," Jag behöver filtrera den till ett visst datumintervall, "det är mycket lättare att göra.
Vi har sett typ av dessa extra roller, som produktchefer, kanske folk i säljoptioner, som börjar plocka upp och som alltid ville lära sig SQL och börja plocka upp det genom att använda denna katalog. Vi har också sett att många företag har försökt göra slags open source. Ive försökte bygga sådana saker internt, där de spårar frågorna och gör dem tillgängliga, och det finns några riktiga slags svåra designutmaningar för att göra dem användbara. har haft ett internt verktyg som de kallade HiPal den typen av fångade alla frågor skrivna på Hive, men vad du hittar är att om du inte snubbla användarna på rätt sätt, du bara slutar med en mycket lång lista av utvalda uttalanden. Och som en användare som försöker ta reda på om en fråga är användbar för mig eller om det är bra, om jag bara går igenom en lång lista med utvalda uttalanden, kommer det att ta mig mycket längre tid att få något ur värde där än från början. Vi tänkte ganska noga över hur man gör en frågekatalog som tar fram rätt saker framtill och ger det på ett användbart sätt.
Dez Blanchfield: Jag tror att vi alla går igenom denna resa från en mycket ung ålder, till vuxen ålder på många sätt. En massa tekniker. Jag, jag själv, har gått igenom samma äkta sak, som att lära mig att skära kod. Jag skulle gå igenom tidskrifter och sedan böcker, och jag skulle studera till en viss nivå, och sedan behövde jag gå och faktiskt få lite mer utbildning och utbildning på det.
Men oavsiktligt upptäckte jag att även när jag gick från att lära mig själv och läsa tidskrifter och läsa böcker och hugga andra folkprogram och gå på kurser på det så slutade jag fortfarande lika mycket av att göra kurserna som jag bara pratade med andra människor som hade några upplevelser. Och jag tror att det är en intressant upptäckt att, nu när du tar med det till dataanalys, i grund och botten såg samma parallell, att människor alltid är ganska smarta.
Det andra jag verkligen är intresserad av att förstå är att på en mycket hög nivå kommer många organisationer att fråga, "Hur lång tid tar det att komma till den punkten?" installerat och de började upptäcka vilka typer av verktyg? Hur snabbt är människor bara att se den här saken förvandlas till ett riktigt omedelbart "a-ha" ögonblick där de inser att de inte ens oroar sig för ROI längre eftersom det är där, men nu ändrar de faktiskt hur de gör affärer? Och de har upptäckt en förlorad konst och de förväntar sig att de kan göra något riktigt, riktigt roligt med det.
David Crawford: Ja, jag kan beröra det lite. Jag tror att när vi installeras, att en av de trevliga sakerna, en av de saker som folk gillar med en katalog som är direkt ansluten till datasystemen, är att du inte startar tomt där du måste fylla i den sida sida. Och detta är sant av tidigare datalösningar där du börjar med ett tomt verktyg och du måste börja skapa en sida för allt du vill dokumentera.
Eftersom vi automatiskt dokumenterar så många saker genom att extrahera metadata, i huvudsak inom några dagar efter att ha installerat programvaran, kan du ha en bild av din datamiljö som är minst 80 procent där i verktyget. Och sedan tror jag att så snart folk börjar skriva frågor med verktyget sparas de automatiskt tillbaka i katalogen, och så kommer de också att dyka upp.
Jag vill inte vara över ivrig när det gäller att ange det. Jag tror att två veckor är en ganska bra konservativ uppskattning, till en månad. Två veckor till en månad, konservativ uppskattning av att verkligen vända dig och känna att du får värde ur det, som att du börjar dela lite kunskap och kunna gå dit och ta reda på saker om dina data.
Dez Blanchfield: Det är ganska förvånande, verkligen när du tänker på det. Det faktum att några av de stora dataplattformarna som du effektivt indexerar och katalogiserar kommer ibland att ta upp till år att implementera och distribuera och stå upp ordentligt.
Den sista frågan jag har fått för dig innan jag överlämnar till Robin Bloor, är kontakter. En av de saker som omedelbart hoppar ut mot mig är att du självklart har fått ut hela utmaningen. Så det är ett par frågor bara riktigt snabbt. En, hur snabbt implementeras anslutningar? Uppenbarligen börjar du med den största plattformen, som Oracle och Teradatas och så vidare och DB2. Men hur regelbundet ser du att nya kontakter kommer igenom, och vilken väntetid tar de? Jag kan tänka mig att du har en standardram för dem. Och hur djupt går du in i dessa? Till exempel Oracle's och IBMs i världen, och till och med Tereadata, och sedan några av de mer populära av sena open source-plattformar. Arbetar de direkt med dig? Upptäcker ni det själva? Måste du ha inre kunskap på dessa plattformar?
Hur ser det ut för att sortera ett kontaktdon och hur djupt engagerar du dig i dessa partnerskap för att säkerställa att dessa kontakter upptäcker allt du kan?
David Crawford: Ja, det är en fantastisk fråga. Jag tror att vi för det mesta kan utveckla kontakterna. Vi gjorde det verkligen när vi var en yngre start och hade inga kunder. Vi kan säkert utveckla anslutningarna utan att behöva någon intern åtkomst. Vi får aldrig någon speciell åtkomst till de datasystem som inte finns tillgängliga offentligt, och ofta utan att behöva någon inre information. Vi drar nytta av metadatatjänsterna tillgängliga av själva datasystemen. Ofta kan de vara ganska komplexa och svåra att arbeta med. Jag känner SQL Server särskilt, hur de hanterar frågeloggen, det finns flera olika konfigurationer och det är något du verkligen måste arbeta med. Du måste förstå nyanserna och knopparna och ratten på den för att ställa in den ordentligt, och det är något som vi arbetar med kunder på eftersom vi har gjort det flera gånger tidigare.
Men till en viss utsträckning, dess typ av offentliga API: er som är tillgängliga eller offentliga gränssnitt som är tillgängliga som vi utnyttjar. Vi har partnerskap med flera av dessa företag, det är mestadels en grund för certifiering, så att de känner sig bekväma med att säga att vi arbetar och även de kan ge oss resurser för testning, ibland tidig tillgång kanske till en plattform som kommer ut för att se till att vi arbetar med de nya versionerna.
För att vända en ny anslutning, skulle jag säga igen, försöker vara konservativ, låt oss säga sex veckor till två månader. Det beror på hur likartat det är. Så några av Postgre-verken ser på samma sätt ut som Redshift. Redshift och Vertica delar mycket av sina detaljer. Så vi kan dra nytta av dessa saker. Men ja, sex veckor till två månader skulle vara rättvist.
Vi har också API: er, så att - vi tänker på Alation som en metadataplattform också, så om något som inte finns tillgängligt för oss att nå ut och automatiskt ta tag, finns det sätt att du kan skriva kontakten själv och trycka in det i vårt system så att allt fortfarande blir centraliserat i en enda sökmotor.
Dez Blanchfield: Fantastisk. Jag uppskattar det. Så skulle överlämna det till Robin, för jag är säker på att han också har en mängd frågor. Robin?
Rebecca Jozwiak: Robin kan vara på stum.
Dez Blanchfield: Du har tagit dig på stum.
Robin Bloor: Ja visst. Ledsen, jag tystade mig själv. Vad är processen när du implementerar detta? Jag är typ av nyfiken eftersom det kan finnas mycket data på många ställen. Så hur fungerar det?
David Crawford: Ja visst. Vi går in, först sin typ av en IT-process för att se till att våra servrar tillhandahålls, se till att nätverksanslutningar är tillgängliga, att portarna är öppna så att vi faktiskt kan komma åt systemen. De vet alla ofta vilka system de vill börja med. Att känna inuti ett datasystem, vilket - och ibland vi faktiskt kommer att hjälpa dem. Hjälp dem att gå en första titt på deras frågellogg för att förstå vem som använder vad och hur många användare de har på ett system. Så bra hjälp med att ta reda på var - de ofta, om de har hundratals eller tusentals människor som kanske loggar in i databaser, vet de faktiskt inte var de loggar in, så vi kan ta reda på ifråga loggar hur många unika användarkonton gör du har faktiskt loggat in och kör frågor här om en månad eller så.
Så vi kan dra nytta av det, men ofta bara på de viktigaste. Vi får dem inrättade och sedan finns det en process att säga: "Låter prioritera." Det finns en rad aktiviteter som kan hända parallellt. Jag skulle fokusera på utbildningen för att använda frågaverktyget. När människor börjar använda frågaverktyget älskar det för det första många att det bara är ett enda gränssnitt till alla sina olika system. De älskar också det faktum att dess webbaserade, inte innebär några installationer om de inte vill. Ur säkerhetssynpunkt gillar de att ha en slags inmatningspunkt, från ett nätverkssynpunkt, mellan ett slags IT-nätverk och det datacenter där produktionsdatakällorna bor. Och så kommer de att ställa in Alation som ett frågaverktyg och börja använda Compose som en åtkomstpunkt för alla dessa system.
Så när det händer, vad vi fokuserar på där på utbildning, är att förstå vad som är några av skillnaderna mellan ett webbaserat eller ett serverbaserat frågaverktyg kontra ett du har på skrivbordet, och några av nyanserna att använda det. Och samtidigt som det väl försöker göra är att identifiera de mest värdefulla uppgifterna, igen utnyttja informationen om frågeloggen och säga: ”Hej, du kanske vill gå in och hjälpa människor att förstå dessa. Låt oss börja publicera representativa frågor på dessa tabeller. ”Det är ibland det mest effektiva sättet att mycket snabbt få människor att snurra upp. Låt oss titta på din egen fråghistorik, publicera dessa saker så att de dyker upp som de första frågorna. När folk tittar på en tabellsida kan de se alla frågor som rörde tabellen och de kan börja därifrån. Och låt oss sedan börja lägga till titlar och beskrivningar till dessa objekt så att de är lättare att hitta och söka, så att du känner till några nyanser av hur du använder dem.
Vi ser till att vi får en grundlig titt på frågeloggen så att vi kan generera avstamning. En av sakerna vi gör är att vi tittar igenom frågeloggen ibland när data flyttas från en tabell till en annan, och som gör att vi kan lägga en av de vanligaste frågorna om en datatabell är, var kom detta ifrån? Hur litar jag på det? Och det vi kan visa är inte bara vilka andra tabeller det kom från, utan hur det transformerades på vägen. Återigen, detta är typ av drivs av fråga loggen.
Så vi ser till att dessa saker är konfigurerade och som började släkt in i systemet och riktade oss till de mest värdefulla och de mest häftiga metadatbitarna som vi kan etablera oss på tabellsidorna, så att när du söker, du hittar något användbart.
Robin Bloor: Okej. Den andra frågan - det finns en massa frågor från publiken, så jag vill inte ta upp för mycket av tiden här - den andra frågan som den typen av kommer att tänka på är bara smärtpunkterna. Många mjukvaror köpt eftersom människor på ett eller annat sätt har svårigheter med något. Så vad är den vanliga smärtpunkten som leder människor till Alation?
David Crawford: Ja. Jag tror att det finns några, men jag tror att en av de som vi hör ganska ofta är analytiker ombord. "Jag kommer att behöva anställa 10, 20, 30 personer på kort sikt som kommer att behöva producera nya insikter från dessa uppgifter, hur kommer de att ta fart?" Så analytiker ombord är något vi säkert tacklar. Det är också bara att befria senioranalytikerna från att spendera all sin tid på att svara på frågor från andra människor om data. Det är också mycket frekvent. Och båda dessa är i huvudsak utbildningsproblem.
Och då skulle jag säga en annan plats som vi ser att folk antar Alation är när de vill skapa en helt ny datamiljö för någon att arbeta i. De vill annonsera och marknadsföra detta internt för att människor ska kunna dra nytta av. Att göra Alation i framkant för den nya analytiska miljön är väldigt tilltalande. Det har fått dokumentationen, det har en enda punkt för introduktion till - en enda punkt för åtkomst till systemen, och så det är en annan plats där människor kommer till oss.
Robin Bloor: Okej, jag kommer att vidarebefordra dig till Rebecca eftersom publiken försöker komma till dig.
Rebecca Jozwiak: Ja, vi har många riktigt bra publikfrågor här. Och David, den här ställdes specifikt till dig. Det kommer från någon som uppenbarligen har lite erfarenhet av människor som missbrukar frågor, och han säger typ att ju mer vi stärker användare, desto svårare är det att styra ansvarsfull användning av beräkningsresurser. Så kan du försvara dig mot spridning av felaktiga men vanliga frågeställningar?
David Crawford: Ja, jag ser den här frågan. Det är en fantastisk fråga - en vi får ganska ofta. Jag har sett smärtan själv hos tidigare företag, där du behöver utbilda användare. Till exempel, "Detta är en loggtabell, dess loggar går tillbaka i flera år. Om du kommer att skriva en fråga på den här tabellen måste du verkligen begränsa efter datum. ”Så, till exempel, det är en utbildning som jag gick vid ett tidigare företag innan jag fick tillgång till databasen.
Vi har några sätt att försöka ta itu med. Jag skulle säga att jag tycker att data om fråga logg är verkligen unikt värdefullt för att hantera den. Det ger en annan inblick jämfört med vad databasen gör internt med sin frågeplanerare. Och vad vi gör är ett av dessa ingripanden - vi har de manuella ingrepp som jag visade, och det är användbart, eller hur? Så på en viss koppling, till exempel, kan du säga "Låter avskriva detta." Det kommer att ha en stor röd flagga när den dyker upp i smarta förslag. Så det är ett sätt att försöka komma till människor.
En annan sak som vi gör är att automatisera vid genomförande-tidsåtgärder. Det kommer faktiskt att använda parse-trädet i frågan innan vi kör det för att se, inkluderar det ett visst filter eller ett par andra saker som vi gör där också. Men en av de mest värdefulla och den enklaste att förklara är, inkluderar det ett filter? Så som det exemplet jag just gav, den här loggtabellen, om du kommer att fråga den, måste ha ett datumintervall, kan du ange i tabellsidan där du vill att det datumintervallfilter ska tillämpas. Om någon försöker köra en fråga som inte innehåller det filtret kommer det faktiskt att stoppa dem med en stor varning, och den kommer att säga, "Du borde förmodligen lägga till en SQL som ser ut så här i din fråga." De kan fortsätta om de vill . Tänkte faktiskt inte helt förbjuda dem att använda det - det är också en fråga, den måste i slutet av dagen köra frågor. Men vi lägger en ganska stor barriär framför dem och vi ger dem ett förslag, ett konkret tillämpligt förslag för att ändra frågan för att förbättra deras prestanda.
Vi gör det faktiskt också automatiskt i vissa fall, igen genom att observera frågeloggen. Om vi ser att några riktigt stora procentandelar av frågorna i den här tabellen drar nytta av ett visst filter eller en viss kopplingsklausul, väljer det faktiskt upp. Främja det till en intervention. Egentligen hände det mig på en intern datauppsättning. Vi har kunddata och vi har användar-ID, men användar-ID-set, eftersom det är - vi har användar-ID för varje kund. Det är inte unikt, så du måste koppla ihop det med ett klient-ID för att få en unik kopplingsnyckel.Och jag skrev en fråga och jag försökte analysera något och det dykte upp och sa: ”Hej, alla andra verkar gå med i dessa tabeller med både klient-ID och användar-ID. Är du säker på att du inte vill göra det? ”Och det hindrade mig faktiskt från att göra en felaktig analys. Så det fungerar både för analysens noggrannhet och prestanda. Så det är sånt hur vi tar det problemet.
Rebecca Jozwiak: Det verkar för mig vara effektivt. Du sa att du inte nödvändigtvis kommer att blockera människor från att ta upp resurser, men lär dem på något sätt att det de gör är inte bäst, eller hur?
David Crawford: Vi antar alltid att användarna inte är skadliga - ge dem de bästa avsikterna - och vi försöker vara ganska öppna på det sättet.
Rebecca Jozwiak: Okej. Här är en annan fråga: "Vad är skillnaden mellan en kataloghanterare, som med din lösning, och ett MDM-verktyg? Eller förlitar den sig faktiskt på en annan princip genom att utvidga valet av frågetabeller, medan MDM skulle göra det automatiskt, men med samma underliggande princip för att samla in metadata. "
David Crawford: Ja, jag tror att när jag tittar på traditionella MDM-lösningar är den primära skillnaden filosofisk. Det handlar om vem användaren är. Som jag sa i början av min presentation, Alation, jag tror att när vi grundades grundades vi med syftet att göra det möjligt för analytiker att producera mer insikter, att producera dem snabbare, att vara mer exakta i de insikter som de producera. Jag tror inte att det någonsin har varit målet för en traditionell MDM-lösning. Dessa lösningar tenderar att vara riktade mot människor som behöver producera rapporter om vilken information som har samlats in till SCC eller internt för någon annan typ av revisionsändamål. Det kan ibland möjliggöra analytiker, men dess oftare, om det kommer att möjliggöra en utövare i deras arbete, är det mer troligt att det möjliggör en dataarkitekt som en DBA.
När du tänker på saker ur en analytikers synvinkel, det är när du börjar bygga ett frågaverktyg som ett MDM-verktyg aldrig skulle göra. Det är när du börjar tänka på prestanda såväl som noggrannhet samt förstå vilka uppgifter som rör mitt affärsbehov. Alla dessa saker är saker som dyker upp i vårt sinne när vi utformar verktyget. Det går in i våra sökalgoritmer, det går in i katalogsidornas layout och förmågan att bidra med kunskap från hela organisationen. Det går in i det faktum att vi byggde frågaverktyget och att vi byggde katalogen direkt i det, så jag tror att det verkligen kommer från det. Vilken användare har du först i åtanke?
Rebecca Jozwiak: Okej, bra. Det hjälpte verkligen till att förklara det. som dör för att få tag i arkiven eftersom han var tvungen att lämna, men han ville verkligen att hans fråga skulle besvaras. Han sa att det nämndes i början att det finns flera språk, men är SQL det enda språket som används inom Komposkomponenten?
David Crawford: Ja det är sant. Och en av de saker som jag har lagt märke till, eftersom jag på något sätt bevittnat explosionen av de olika typerna av databaser, av dokumentdatabaser, av grafidatabaser, av viktiga värdeförråd, är att de verkligen är kraftfulla för applikationsutveckling. De kan tjäna särskilda behov där riktigt bra, på bättre sätt än vad relationella databaser kan.
Men när du tar tillbaka den till dataanalys, när du tar tillbaka den till - när du vill tillhandahålla den informationen till personer som ska göra ad hoc-rapportering eller ad hoc-grävningar i uppgifterna, att de alltid kommer tillbaka till en relation åtminstone gränssnitt för människorna. En del av det är bara för att SQL är lingua franca för dataanalys, så det betyder för människorna det också för de verktyg som integreras. Jag tror att detta är anledningen till att SQL på Hadoop är så populärt och det finns så många försök att lösa det, beror på att det i slutet av dagen är vad folk vet. Det finns förmodligen miljoner människor som vet hur man skriver SQL, och jag skulle inte våga miljoner som vet hur man skriver en Mongo-aggregeringsrörledningsprogram. Och att det är ett standardspråk som används för integration på ett riktigt stort antal plattformar. Så allt detta sägs, blev mycket sällan ombedd att gå utanför det eftersom detta är det gränssnitt som de flesta analytiker använder, och det är en plats där vi fokuserade, särskilt i Compose, att vi fokuserade på att skriva SQL.
Jag skulle säga datavetenskap är den plats där de vågar utanför det mesta, och så får vi ibland frågor om att använda gris eller SAS. Det här är saker som vi definitivt inte hanterar i Compose, och som vi vill fånga i katalogen. Och jag ser också R och Python. Vi har ett par sätt att vi har gjort gränssnitt som du kan använda frågorna skrivna i Alation inuti R- och Python-skript, så eftersom du ofta är en datavetare och du arbetar på ett skriptspråk är dina källdata i ett relation databas. Du börjar med en SQL-fråga och sedan bearbetar du den ytterligare och skapar grafer inuti R och Python. Och vi har gjort paket som du kan importera till de skript som drar frågorna eller frågeställningarna från Alation så att du kan ha ett blandat arbetsflöde där.
Rebecca Jozwiak: Okej, bra. Jag vet att vi har gått lite förbi timmen, jag ska bara ställa en eller två frågor till. Jag vet att du har pratat om alla de olika systemen som du kan ansluta till, men när det gäller extern värddata och internvärddata, kan det tillsammans sökas i din enda vy, till din enda plattform?
David Crawford: Säker. Det finns några sätt att göra det på. Jag menar, extern värd, skulle jag föreställa mig, jag försöker tänka på exakt vad det kan betyda. Det kan betyda en databas som någon är värd i AWS för dig. Det kan betyda en offentlig datakälla från data.gov. Vi ansluter direkt till databaser genom att logga in precis som en annan applikation med, med ett databas-konto, och det är hur vi extraherar metadata. Så om vi har ett konto och har en nätverksport öppen kan vi komma till det. Och när vi inte har dessa saker, har vi något som kallas en virtuell datakälla, som låter dig väsentligen driva dokumentation, vare sig automatiskt, genom att skriva din egen kontakt eller genom att fylla i den genom att göra till och med som en CSV-uppladdning, för att dokumentera data bredvid dina interna data. Det blir allt placerat i sökmotorn. Det blir referenserbart inuti artiklar och annan dokumentation och konversationer i systemet. Så det är så vi hanterar när vi inte direkt kan ansluta till ett system.
Rebecca Jozwiak: Okej, det är vettigt. Jag ska bara skjuta ut ytterligare en fråga till dig. En deltagare är frågar: "Hur ska innehållet i en datakatalog verifieras, verifieras eller upprätthållas, då källdata uppdateras, då källdata ändras etc."
David Crawford: Ja, det är en fråga vi får mycket, och jag tror att en av de saker som vi - en av våra filosofier, som jag sa, tror vi inte att användarna är skadliga. Vi antar att de försöker bidra med den bästa kunskapen. De kommer inte att komma in och vilseleda människor medvetet om uppgifterna. Om det är ett problem i din organisation, kanske Alations inte det rätta verktyget för dig. Men om du antar goda avsikter från användarna, så tänker vi på det som något där, uppdateringarna kommer in, och då brukar vi göra en förvaltare som ansvarar för varje dataobjekt eller varje sektion av data. Och vi kan meddela de förvaltare när ändringar av metadata görs och de kan hantera det på det sättet. De ser uppdateringar komma in, de validerar dem. Om de inte har rätt, kan de gå tillbaka och ändra dem och informera, och förhoppningsvis även nå ut till användaren som har bidragit med informationen och hjälpa dem att lära sig.
Så det är det primära sättet vi funderar på att göra det på. Den här typen av förslag från publiken och ledningen av förvaltarna, så vi har vissa kapaciteter runt det.
Rebecca Jozwiak: Okay bra. Och om du bara kunde låta folk veta hur de bäst kan komma igång med Alation, och vart kan de gå specifikt för att få mer information. Jag vet att du delade det en bit. Är det det bästa stället?
David Crawford: Alation.com/learnmore Jag tycker är ett bra sätt att gå. För att registrera dig för en demo har Alation.com-webbplatsen mycket bra resurser, kundböcker och nyheter om vår lösning. Så jag tycker att det är ett bra ställe att börja. Du kan också .
Rebecca Jozwiak: Okej, bra. Och jag vet, deltagare, ledsen om jag inte fick alla frågorna idag, men om inte, kommer de att vidarebefordras till David eller hans säljteam eller någon på Alation, så de kan definitivt hjälpa till att svara på dina frågor och hjälpa till att förstå vad Alation gör eller vad de gör bäst.
Och med det, folkens, ska jag gå vidare och skriva ut oss. Du kan alltid hitta arkiven på InsideAnalysis.com. Du kan också hitta det på Techopedia.com. De tenderar att uppdatera lite snabbare, så definitivt kolla in det. Och tack så mycket till David Crawford, Dez Blanchfield och Robin Boor idag. Det har varit en bra webcast. Och med det säger jag dig farväl. Tack, folkens. Hejdå.
David Crawford: Tack.