Door Techopedia Staff, 22 juni 2016
Takeaway: Host Rebecca Jozwiak bespreekt de voordelen van datacatalogi met Dez Blanchfield, Robin Bloor en David Crawford.
Je moet je registreren voor dit evenement om de video te bekijken. Registreer om de video te bekijken.
Rebecca Jozwiak: dames en heren, hallo en welkom bij Hot Technologies van 2016. Vandaag hebben we: "De kracht van suggestie: hoe een gegevenscatalogus analisten ondersteunt." Ik ben uw gastheer Rebecca Jozwiak, die invult voor onze gebruikelijke gastheer Eric Kavanagh vandaag, terwijl hij de wereld rondreist, dus bedankt voor je komst. Dit jaar is hot, het is niet alleen hot in Texas waar ik ben, maar het is overal hot. Er komt een explosie van allerlei nieuwe technologieën uit. We hebben IoT, streaming data, cloudacceptatie, Hadoop blijft volwassen en geadopteerd worden. We hebben automatisering, machine learning, en al deze dingen worden natuurlijk onderstreept door gegevens. En ondernemingen worden met de dag meer en meer data gestuurd. En het doel is natuurlijk om te leiden tot kennis en ontdekking en, je weet wel, betere beslissingen te nemen. Maar om echt de meeste waarde uit gegevens te halen, moet het gemakkelijk te bereiken zijn. Als je het opgesloten, of begraven, of in de hersenen van een paar mensen binnen de onderneming houdt, zal het niet veel goeds doen voor de onderneming als geheel.
En ik dacht een beetje na over gegevenscatalogus en dacht natuurlijk aan bibliotheken, waar je lang geleden naar toe ging als je iets moest vinden, als je een onderwerp moest onderzoeken of wat informatie moest opzoeken, je naar de bibliotheek ging, en natuurlijk ging je naar de kaartenbak, of de slechtgehumeurde dame die daar werkte. Maar het was ook leuk om een beetje rond te dwalen, als je alleen maar wilde kijken, en er zeker van zou zijn dat je net iets leuks zou ontdekken, zou je misschien een aantal interessante feiten kunnen ontdekken die je nog niet wist, maar als je echt iets moest weten, en je wist wat je zocht, je had de kaartcatalogus nodig, en natuurlijk is het enterprise-equivalent een datacatalogus, die kan helpen alle gegevens te laten schijnen zodat onze gebruikers kunnen verrijken, ontdekken, delen, consumeren en echt helpen mensen krijgen gegevens sneller en gemakkelijker.
Dus vandaag hebben we Dez Blanchfield, onze eigen datawetenschapper, en we hebben Doctor Robin Bloor, onze eigen hoofdanalist, we hebben David Crawford van Alation, die gaat praten over het verhaal van zijn bedrijfscatalogus, maar eerst we gaan beginnen met Dez. Dez, ik geef de bal aan jou en de vloer is van jou.
Dez Blanchfield: Bedankt, bedankt dat je me vandaag hebt. Dit is een kwestie waar ik enorm in geïnteresseerd ben, omdat bijna elke organisatie die ik tegenkom in mijn dagelijkse werk, ik precies dezelfde kwestie vind waar we het heel kort over hadden in de pre-show scherts, en dat is dat de meeste organisaties die meer dan een paar jaar in bedrijf zijn, hebben een overvloed aan gegevens begraven rond de organisatie, verschillende formaten, en in feite heb ik klanten met gegevenssets die teruggaan naar Lotus Notes, databases die nog steeds in sommige gevallen als hun pseudo-internets, en zij komen allemaal in de uitdaging om daadwerkelijk te vinden waar hun gegevens zijn, en hoe ze toegang kunnen krijgen, wie ze toegang kunnen geven, wanneer ze toegang moeten krijgen en hoe ze catalogus, en hoe het op een plaats te krijgen waar iedereen kan: A) zich bewust zijn van wat er is en wat erin staat, en B), hoe toegang te krijgen tot het en het te gebruiken. En een van de grootste uitdagingen is natuurlijk om het te vinden, de andere grote uitdaging is om te weten wat erin zit en hoe je er toegang toe kunt krijgen.
Ik weet misschien wel dat ik tientallen databases heb, maar ik weet eigenlijk niet wat erin zit of hoe ik erachter kan komen wat erin zit, en zoals altijd ontdekken we nu in de pre-show data om door het kantoor te lopen en vragen te stellen, over de kubieke muren te schreeuwen en uit te zoeken, vaak is mijn ervaring dat je misschien zelfs merkt dat je naar de receptie, de receptie loopt en vraagt of iemand weet wie je gaat met praten. Heel vaak zijn het niet altijd de IT-mensen omdat ze zich niet bewust zijn van de gegevensset omdat iemand deze zojuist heeft gemaakt, en het kan iets eenvoudigs zijn als een - heel vaak vinden we een soort project dat rechtop staat in de IT-omgeving en de projectmanager heeft een spreadsheet van alle dingen gebruikt, en het heeft een enorme hoeveelheid waardevolle informatie gekregen over middelen en context en namen, en tenzij je dat project kent en je kent die persoon, kun je die informatie gewoon niet vinden. Het is gewoon niet beschikbaar, en je moet dat originele bestand te pakken krijgen.
Er is een zin die gekwetst is met betrekking tot gegevens en ik ben het er niet noodzakelijk mee eens, maar ik vind het een schattige kleine weggooi en dat is dat een bepaald aantal mensen denken dat gegevens de nieuwe olie zijn, en ik ben we gaan dit later op een of andere manier ook behandelen. Maar wat mij is opgevallen, zeker als onderdeel van die transformatie, is dat organisaties van bedrijven die hebben geleerd hun gegevens te waarderen, aanzienlijk voordeel hebben verworven ten opzichte van hun concurrenten.
Er was een interessant artikel van IBM, ongeveer vijf of zes jaar geleden, en ze ondervroegen ongeveer 4.000 bedrijven hier in Australië, en ze namen alle informatie, alle prestatiegegevens, alle financiële gegevens en legden ze samen in een kookpot en vervolgens stuurde het naar de Australian School of Economics, en ze begonnen hier eigenlijk een gemeenschappelijke trend, en dat was dat bedrijven die technologie gebruikten steevast zo een concurrentievoordeel hebben verkregen ten opzichte van hun collega's en concurrenten als zodanig dat hun concurrenten bijna nooit inhalen, en ik denk dat dat is nu heel erg het geval met gegevens die we hebben gezien wat mensen een digitale transformatie noemen, waarbij organisaties die duidelijk hebben bedacht hoe ze gegevens kunnen vinden die ze hebben, om die gegevens beschikbaar te maken en beschikbaar te maken in een zeer gemakkelijk te consumeren gegevens. mode voor de organisatie, zonder noodzakelijkerwijs altijd te weten waarom de organisatie het nodig zou kunnen hebben, en aanzienlijk voordeel te behalen ten opzichte van concurrenten.
Ik heb een paar voorbeelden op deze dia, die je kunt zien. Mijn enige opstelling is dat de grootschalige verstoring in bijna elke sector naar mijn mening wordt aangedreven door gegevens, en als de huidige trends iets zijn om te volgen, zijn mijn mening dat we pas echt net zijn begonnen omdat wanneer de oude merken eindelijk wakker worden wat dit betekent en in het spel komen, ze het spel in de groothandel gaan betreden. Wanneer een soort van de grote detailhandelaren met bergen gegevens een historische analyse van de gegevens gaan toepassen, als ze zelfs weten dat deze bestaat, dan zullen sommige online spelers een beetje wakker worden.
Maar met veel van deze merken bedoel ik dat we Uber hebben, het grootste taxibedrijf ter wereld. Ze bezitten geen taxi's, dus wat maakt hen magisch, wat zijn hun gegevens? Airbnb, de grootste aanbieder van accommodaties, we hebben WeChat, het grootste telefoonbedrijf ter wereld, maar ze hebben geen echte infrastructuur en geen handsets, geen telefoonlijnen. Alibaba, de grootste retailer ter wereld, maar ze bezitten geen enkele voorraad. Facebook, het grootste mediabedrijf ter wereld. Ik denk dat ze bij de laatste telling nu 1, 4 miljard actieve gegevensgebruikers hadden, wat een verbijsterend aantal is. Het is niet overal in de buurt - ik denk dat iemand beweerde dat een kwart van de planeet er eigenlijk elke dag is, en toch is hier een contentprovider die de content eigenlijk niet maakt, alle data die ze aanbieden is niet door hen gemaakt, het is gemaakt door hun abonnees, en we kennen dit model allemaal.
SocietyEén, waar je misschien wel of niet van hebt gehoord, het is een lokaal merk, ik denk dat het in een paar landen een bank is die echt peer-to-peer leningen verstrekt, dus met andere woorden, het heeft geen geld. Het enige dat het doet, is het beheren van de transacties en de gegevens zitten eronder. Netflix, we zijn er allemaal heel, heel bekend mee. Er is hier een interessante one-liner. Toen Netflix legaal kon worden gebruikt in Australië, toen het officieel werd aangekondigd, hoefde je geen VPN te gebruiken om het te bereiken, veel mensen over de hele wereld hebben de neiging - als je er niet in je lokale omgeving kunt komen - toen Netfix in Australië werd gelanceerd, verhoogde het de internationale bandbreedte op onze internetlinks met 40 procent, dus verdubbelde het het internetgebruik in Australië bijna meteen met slechts één applicatie, één cloud-gehoste applicatie die niets anders doet dan spelen met gegevens. Het is gewoon een verbijsterende statistiek.
En natuurlijk zijn we allemaal bekend met Apple en Google, maar dit zijn de grootste softwarebedrijven ter wereld, maar ze schrijven de apps niet echt. Wat is consistent met al deze organisaties? Nou, het zijn gegevens, en ze zijn er niet gekomen omdat ze niet wisten waar hun gegevens waren, en ze wisten niet hoe ze deze moesten catalogiseren.
Wat we nu ontdekken, is dat er een hele nieuwe activaklasse wordt aangeduid als data, en bedrijven worden er wakker van. Maar ze hebben niet altijd de tools en de knowhow en de reden om al die gegevens in kaart te brengen, al die gegevens te catalogiseren en beschikbaar te stellen, maar we hebben ontdekt dat bedrijven met vrijwel geen fysieke activa een hoge marktwaarde hebben verworven in recordtijd via deze nieuwe data-activaklasse. Zoals ik al zei, worden sommige van de oude spelers hier nu wakker van en brengen het zeker uit.
Ik ben een grote fan van het meenemen van folk op een klein stukje van de reis, dus in de achttienhonderd, laat achttienhonderd honderden, en je zult dit meer dan bekend zijn op de Amerikaanse markt, het bleek dat het een volkstelling was elk jaar of zo, ik denk dat ze ze op dat moment om de tien jaar hebben gerund, maar als je elk jaar een volkstelling gaat houden, kan het tot acht of negen jaar duren om de gegevensanalyse daadwerkelijk te doen. Het bleek dat die dataset vervolgens in dozen op plaatsen op papier achterbleef, en bijna niemand kon hem vinden. Ze bleven deze rapporten gewoon wegpompen, maar de feitelijke gegevens waren heel moeilijk te bereiken, we hebben een vergelijkbare situatie met een ander belangrijk moment, rond de jaren 1940, met de Tweede Wereldoorlog, en dit ding is de Bletchley Park Bombe gespeld BOMBE, en het was een enorm analytisch hulpmiddel voor het kraken van getallen dat door kleine gegevenssets zou gaan en daarin signalen zou vinden, en zou worden gebruikt om codes te helpen kraken via het Enigma.
Nogmaals, dit ding was in wezen een apparaat ontworpen, niet veel om te catalogiseren, maar om gegevens te taggen en in kaart te brengen, en het mogelijk te maken om patronen te nemen en het in de gegevenssets te vinden, in dit geval breekcodes, sleutels en zinnen zoeken en vinden ze regelmatig in de gegevenssets, en dus hebben we deze reis meegemaakt om dingen in gegevens te vinden en te leiden naar het catalogiseren van gegevens.
En toen kwamen deze dingen, deze enorme goedkope rekken met machines, gewoon kant-en-klare machines. En we hebben een aantal zeer interessante dingen gedaan, en een van de dingen die we met hen hebben gedaan, is dat we zeer goedkope clusters hebben gebouwd die de planeet zouden kunnen indexeren, en zeer beroemd deze grote merken die zijn gekomen en gegaan, maar waarschijnlijk is Google het meest voorkomende huis merk waar we allemaal van hebben gehoord - het is een echt werkwoord geworden, en je weet dat je succesvol bent wanneer je merk een werkwoord wordt. Maar wat Google ons heeft geleerd, zonder het te beseffen, mogelijk in de zakenwereld, is dat ze de hele planeet tot een bepaald niveau konden indexeren en de gegevens van over de hele wereld konden catalogiseren en beschikbaar maken op een zeer eenvoudige, handige vorm in een kleine minuscule formule van één regel, een webpagina met bijna niets erop, en u typt uw zoekopdracht in, die gaat en vindt deze omdat ze de planeet al hadden doorzocht, geïndexeerd en gemakkelijk beschikbaar gemaakt.
En wat ons opviel was: “Wacht even, we doen dit niet in organisaties - waarom is dat? Waarom is dat we een organisatie hebben die de hele planeet in kaart kan brengen en indexeren, crawlen en indexeren en beschikbaar maken, dan kunnen we ernaar zoeken en vervolgens op het ding klikken om het te vinden, hoe komt het dat we dat intern niet gedaan? ”Dus er zijn nu veel van deze kleine racks met machines over de hele wereld die dat doen voor intranetten en dingen vinden, maar ze komen nog steeds echt aan het idee om verder te gaan dan het traditionele web pagina of een bestandsserver.
In plaats van de volgende generatie gegevenscatalogi op vele manieren te betreden, is het ontdekken van gegevenstoegang via post-it-notities en waterkoelergesprekken niet echt een geschikte methode meer voor het ontdekken en catalogiseren van gegevens, en in feite denk ik niet dat het ooit echt was. We kunnen die hele uitdaging niet langer leiden tot mensen die alleen maar notities doorgeven, notities posten en erover praten. We zijn nu ver buiten het gebied waar deze next-gen benadering van gegevenscatalogus is gekomen en gegaan. We moeten er onze armen omheen slaan. Als dit een eenvoudig probleem was, hadden we het al op veel manieren eerder opgelost, maar ik denk dat het geen eenvoudig probleem is, alleen indexeren en de gegevens oproepen is slechts een onderdeel ervan, wetende wat er in de gegevens staat en het bouwen van metadata rond wat we ontdekken en het vervolgens beschikbaar stellen in een gemakkelijke, consumeerbare vorm, met name voor selfservice en analyse. Het is nog steeds een probleem dat wordt opgelost, maar veel delen van de puzzel in vijf jaar zijn goed en echt opgelost en beschikbaar.
Zoals we weten, is het catalogiseren van gegevens door mensen een recept voor mislukking, omdat menselijke fouten een van de grootste nachtmerries zijn waar we mee te maken hebben bij gegevensverwerking, en ik praat regelmatig over dit onderwerp waarbij mensen in mijn ogen waarschijnlijk papieren formulieren invullen de grootste nachtmerrie is we houden ons bezig met big data en analyses, om constant dingen te moeten repareren die ze doen, zelfs tot simpele dingen zoals de datums en velden, mensen die het in het verkeerde formaat zetten.
Maar zoals ik al zei, hebben we gezien dat internetzoekmachines de wereld elke dag indexeren, dus nu komen we op het idee dat dat kan worden gedaan met zakelijke gegevenssets in het ontdekkingsproces, en tools en systemen zijn nu direct beschikbaar zoals u vandaag gaat leren. Dus de truc, echt in mijn ogen, is het selecteren van de juiste tools, de beste tools voor de klus. En nog toepasselijker, het vinden van het juiste deel om u te helpen op dit pad te beginnen. En ik geloof dat we dat vandaag zullen horen, maar voordat we dat doen, ga ik over naar mijn school, Robin Bloor en hoor hij zijn mening over het onderwerp. Robin, mag ik je overgeven?
Robin Bloor: Ja, dat kan zeker. Laten we kijken of dit werkt, oh ja, dat doet het. Oké, ik kom uit een andere richting dan Dez echt, maar ik zal op dezelfde plaats eindigen. Dit gaat over verbinding maken met gegevens, dus ik dacht gewoon dat ik door de realiteit zou lopen van verbinding maken met gegevens, punt voor punt eigenlijk.
Er is een feit dat gegevens meer gefragmenteerd zijn dan ooit tevoren. De hoeveelheid gegevens groeit fenomenaal, maar in feite groeien de verschillende gegevensbronnen ook ongelooflijk snel, en daarom worden gegevens steeds meer gefragmenteerd. Maar vooral vanwege analysetoepassingen - maar dat zijn niet de enige toepassingen - hebben we een heel goede reden om verbinding te maken met al deze gegevens, dus we zitten vast op een moeilijke plek, we zitten vast in een wereld van gefragmenteerde gegevens, en er is gelegenheid in de data zoals Dez het noemde, de nieuwe olie.
Over gegevens, nou ja, vroeger leefde het op een draaiende schijf, hetzij in bestandssystemen of in databases. Nu leeft het in een veel meer gevarieerde omgeving, het leeft in bestandssystemen, maar het leeft tegenwoordig ook in Hadoop-instanties, of zelfs Spark-instanties. Het leeft in meerdere soorten databases. Nog niet zo lang geleden hebben we een soort relationele database gestandaardiseerd, weet je, dat is de afgelopen vijf jaar uit het raam gegaan, omdat er behoefte is aan documentdatabases en er is behoefte aan grafische databases, dus weet je, de game heeft veranderd. Dus het leefde op een draaiende schijf, maar het leeft nu op SSD. De nieuwste hoeveelheid SSD - zeker de nieuwste SSD-eenheid komt uit Samsung - twintig gigabytes, wat enorm is. Nu leeft het in het geheugen, in de zin dat de primaire kopie van gegevens in het geheugen kan zijn, in plaats van op schijf, we hebben niet zulke systemen gebouwd; dat doen we nu. En het leeft in de cloud. Wat betekent dat het in elk van deze dingen kan leven, in de cloud, je hoeft niet noodzakelijk te weten waar het in een cloud is, je hebt alleen het adres.
Om het punt te noemen, had Hadoop tot nu toe gefaald als een uitbreidbare gegevensopslag. We hadden gehoopt dat het een uitbreidbare schaalbare gegevensopslag zou worden, en het zou gewoon één bestandssysteem worden voor alles, en het zou - regenbogen zouden in de lucht verschijnen, in feite, en eenhoorns zouden dansen rond, en niets van dat gebeurde. Dat betekent dat we een probleem van datatransport hebben en dat er soms geen noodzaak is voor datatransport, maar het is ook een probleem. Tegenwoordig heeft data echt zwaartekracht, als je eenmaal in de multi-terabytes aan data bent gekomen, het oppakt en rondgooit, veroorzaakt het soort latencies op je netwerk of op verschillende plaatsen. Als u gegevens wilt vervoeren, is timing een factor. Tegenwoordig zijn er bijna altijd grenzen aan hoeveel tijd je hebt om één ding te krijgen, één data van de ene plaats naar de andere. Vroeger was er wat we altijd als batchvensters beschouwden, toen de machine een beetje inactief was, en ongeacht hoeveel gegevens je had, je kon het gewoon omgooien en het zou allemaal werken. Nou dat is weg, we leven in een veel realtime wereld. Daarom is timing een factor. Zodra u gegevens wilt verplaatsen, dus als de gegevens zwaartekracht hebben, kunt u deze waarschijnlijk niet verplaatsen.
Gegevensbeheer is een factor in de zin dat u al deze gegevens daadwerkelijk moet beheren, u krijgt dat niet gratis, en replicatie kan nodig zijn om de gegevens daadwerkelijk het werk te laten doen dat ze moeten doen, omdat het is misschien niet waar je het hebt neergezet. Het beschikt mogelijk niet over voldoende middelen om de gegevens normaal te verwerken. Dus gegevens worden gerepliceerd en gegevens worden meer gerepliceerd dan u zou denken. Ik denk dat iemand me lang geleden heeft verteld dat het gemiddelde stukje gegevens minstens twee en een half keer wordt gerepliceerd. ESB's of Kafka bieden een optie voor de gegevensstroom, maar tegenwoordig vereist het architectuur. Tegenwoordig moet je echt op een of andere manier nadenken over wat het eigenlijk betekent om de gegevens rond te gooien. Daarom heeft het meestal de voorkeur om toegang te krijgen tot gegevens waar het is, zolang u natuurlijk de prestaties krijgt die u nodig hebt wanneer u daadwerkelijk voor de gegevens gaat en dat hangt af van de context. Dus het is in ieder geval een moeilijke situatie. Wat betreft gegevensquery's, we konden vroeger denken in termen van SQL, we zijn nu echt op de proppen, weet je, verschillende vormen van query's, SQL ja, maar aangrenzende, ook grafiekquery's, Spark is slechts een voorbeeld van grafiek, omdat we ook meer moeten zoeken op tekst, meer dan ooit tevoren, ook regex-type zoekopdrachten, wat echt gecompliceerde zoekopdrachten voor patronen is, en echte patroonovereenkomst, al deze dingen borrelen eigenlijk weg. En ze zijn allemaal nuttig omdat ze u krijgen waar u naar op zoek bent, of ze kunnen u krijgen wat u zoekt.
Query's omvatten tegenwoordig dagen meerdere gegevens, dus dat deed dat niet altijd, en vaak zijn de prestaties verschrikkelijk als je dat doet. Het hangt dus van de omstandigheden af, maar mensen verwachten dat ze gegevens uit meerdere gegevensbronnen kunnen opvragen, dus de een of andere gegevensfederatie wordt steeds actueler. Datavirtualisatie, wat een andere manier is om dit te doen, afhankelijk van de prestaties, is ook heel gebruikelijk. Gegevensvragen zijn eigenlijk een onderdeel van een proces, niet het hele proces. Het is alleen maar de moeite waard om erop te wijzen dat als u daadwerkelijk naar de prestaties van de analyse kijkt, de daadwerkelijke analyse veel langer kan duren dan het verzamelen van gegevens, omdat dat afhankelijk is van de omstandigheden, maar gegevensquery's zijn een absolute noodzaak als u iets wilt doen soort analyses op meerdere gegevensbronnen, en het is gewoon dat u echt over capaciteiten moet beschikken die reiken.
Dus over catalogi. Catalogussen bestaan om een reden, tenminste, we zeggen dat, weet je, het is, we hebben mappen, en we hebben schema's in databases, en we hebben elke catalogus en we hebben waar je ook gaat je een plek zult vinden en dan zul je eigenlijk ontdek dat er een soort catalogus is en dat de verenigde wereldwijde catalogus zo'n duidelijk goed idee is. Maar heel weinig bedrijven hebben zoiets. Ik herinner me nog, in het jaar tweeduizend - het jaar tweeduizend paniek - ik herinner me nog dat communisten niet eens konden vaststellen hoeveel uitvoerbare bestanden ze hadden, laat staan hoeveel verschillende datastores ze hadden, en dat is nu waarschijnlijk het geval, weet je, dat de meeste bedrijven niet actief in globale zin weten welke gegevens ze hebben. Maar het wordt duidelijk steeds noodzakelijker om een wereldwijde catalogus te hebben, of op zijn minst een globaal beeld te hebben van wat er gaande is vanwege de groei van gegevensbronnen en de voortdurende groei van applicaties, en het is met name noodzakelijk voor analyse, omdat je ook op één manier, en er zijn andere problemen hier, zoals afkomst en problemen met de gegevens, en het is noodzakelijk voor de beveiliging, veel aspecten van gegevensbeheer, als je echt niet weet welke gegevens je hebt, het idee dat je gaat regeren is gewoon absurd. Dus dat alle gegevens op de een of andere manier zijn gecatalogiseerd, is slechts een feit. De vraag is of de catalogus coherent is en wat u ermee kunt doen. Dus ik zal teruggaan naar Rebecca.
Rebecca Jozwiak: Oké, bedankt Robin. Vervolgens hebben we David Crawford van Alation, David. Ik ga je gang en geef de bal aan jou, en je kunt hem wegnemen.
David Crawford: Heel erg bedankt. Ik waardeer het echt dat jullie me in deze show hebben. Ik denk dat ik hiermee aan de slag ga, dus ik denk dat mijn rol hier is om een deel van die theorie te nemen en te zien hoe deze daadwerkelijk wordt toegepast, en de resultaten die we kunnen genereren bij echte klanten en zodat je kunt zien een paar op de dia, ik wil het hebben over welke resultaten we in analytische mogelijke verbeteringen kunnen zien. Om de discussie te motiveren, gaan we het hebben over hoe ze daar zijn gekomen. Dus ik heb het geluk dat ik vrij nauw met heel veel slimme mensen, deze klanten, aan de slag kan gaan, en ik wil er slechts een paar aanwijzen die daadwerkelijk hebben kunnen meten en praten over de invloed van een gegevenscatalogus op hun analist workflow. En om even kort aan de voorkant te blijven, denk ik dat een van de dingen die we zien veranderen, met gegevenscatalogi versus eerdere gemedieerde oplossingen en een van de manieren waarop relaties echt nadenken over de oplossingen die we samenstellen, is om te beginnen bij de analisten en werk achteruit. Laten we zeggen dat we de productiviteit van analisten mogelijk maken. In tegenstelling tot alleen compliance, of in tegenstelling tot het hebben van alleen een inventaris, maken we een tool die analisten productiever maakt.
Dus, toen ik met een datawetenschapper van het financiële dienstverlener Square praat, was er een man, Nick, die ons vertelde hoe die van hem, hij deed er een paar uur over om de juiste dataset te vinden om een rapport te starten, nu kan hij doe het in een kwestie van seconden met behulp van zoeken op marktaandeel, we spraken met hun CTO die zijn analisten trok die Square gebruikten, pardon, Alation gebruikten, om te ontdekken wat hun, welke voordelen ze zagen, en ze meldden een 50 procent productiviteitsverhoging, en dat de, een van 's werelds beste retailers, eBay, meer dan duizend mensen hebben die regelmatig SQL-analyses uitvoeren, en ik werk daar vrij nauw samen met Deb Says, wie is het project manager in hun datatoolteam, en ze ontdekte dat wanneer queriers Alation adopteren, een catalogus adopteren, ze het dubbele zien van de snelheid van het schrijven van nieuwe query's in de database.
Dit zijn dus echte resultaten, dit zijn mensen die de catalogus daadwerkelijk in hun organisatie toepassen, en ik wil u doornemen wat nodig is om het op te zetten. Hoe een catalogus tot stand komt in een bedrijf, en misschien het belangrijkste om te zeggen, is dat veel ervan automatisch gebeurt, dus Dez heeft gesproken over systemen, leren over systemen, en dat is precies wat een moderne gegevenscatalogus doet. Dus installeren ze Alation in hun datacenter en verbinden ze het vervolgens met verschillende bronnen van metadata in hun data-omgeving. Ik zal me een beetje concentreren op de databases en de BI-tools - van beide gaan we technische metadata extraheren, over in feite wat er bestaat. Juist, dus welke tafels? Welke rapporten? Wat zijn de rapportdefinities? Dus extraheren ze die technische metadata, en er wordt automatisch een cataloguspagina gemaakt voor elk object binnen die systemen, en vervolgens extraheren en plaatsen ze bovenop die technische metadata, ze leggen bovenop de gebruiksgegevens. Dat wordt voornamelijk gedaan door querylogboeken uit de database te lezen, en dit is echt een interessante informatiebron. Dus, wanneer een analist een vraag schrijft, wanneer een rapportagetool, of deze nu in eigen beheer is, of van de plank, of een rapportagetool een query uitvoert om het dashboard bij te werken, wanneer een toepassing een query uitvoert om gegevens in te voegen om op te werken een gegevensset - al die dingen worden vastgelegd in databasequerylogboeken. Of u nu een catalogus hebt of niet, ze worden vastgelegd in het querylogboek met de database. Wat een datacatalogus kan doen, en vooral wat de catalogus van Alation kan doen, is die logboeken lezen, de query's erin vragen en een echt interessante gebruiksgrafiek maken op basis van die logboeken, en we brengen dat in het spel om toekomstige gebruikers te informeren van de gegevens over hoe eerdere gebruikers van de gegevens deze hebben gebruikt.
Dus we brengen al die kennis samen in een catalogus, en om dit echt te maken, dit zijn de integraties die al bij klanten worden geïmplementeerd, dus we hebben Oracle, Teradata, Redshift, Vertica en een heleboel andere gezien relationele databases. In de Hadoop-wereld is er een reeks SQL op Hadoop, soort relationele meta-winkels bovenop het Hadoop-bestandssysteem, Impala, Tez, Presto en Hive, we hebben ook succes gezien met cloud Hadoop-particuliere providers zoals Altiscale, en we zijn ook in staat geweest om verbinding te maken met Tableau-servers, MicroStrategy-servers en de dashboards daar te indexeren, evenals integratie met data science-grafieken zoals Plotly.
Dus we maken verbinding met al deze systemen, we hebben deze systemen met klanten verbonden, we hebben de technische metadata binnengehaald, we hebben de gebruiksgegevens opgehaald en we hebben de gegevenscatalogus min of meer automatisch voorbereid, maar op die manier hebben we centraliseer de kennis, maar alleen dingen centraliseren in een datacatalogus, levert op zichzelf niet echt die geweldige productiviteitsverhogingen op waar we het over hadden met eBay, Square en marktaandeel. Om dat te doen, moeten we eigenlijk de manier veranderen waarop we denken over het leveren van kennis aan analisten. Een van de vragen die ze stellen om zich hierop voor te bereiden, was: "Welke invloed heeft de catalogus op de workflow van een analist?"
Dat is waar we de hele dag over nadenken, en om te praten over deze verandering in denken, van een push versus een pull-model, wilde ik een snelle analogie maken met hoe de wereld was voor en na het lezen op een Kindle. Dus het is gewoon een ervaring die sommigen van jullie misschien hebben, als je een fysiek boek leest, kom je een woord tegen, je weet niet zeker of je de definitie van dat woord heel goed kent, je kunt het misschien raden vanuit de context, niet zo waarschijnlijk dat je ga van de bank opstaan, loop naar je boekenplank, vind je woordenboek, stof het af en blader naar de juiste plaats in de alfabetische lijst van woorden om ervoor te zorgen dat, ja je had die definitie precies goed, en je weet de nuances ervan. Dus het gebeurt niet echt. Dus je koopt een Kindle-app en begint boeken te lezen, en je ziet een woord waar je niet helemaal zeker van bent en je raakt het aan. Plots, precies in hetzelfde scherm, is de woordenboekdefinitie van het woord, met al zijn nuances, verschillende voorbeeldgebruiken, en je veegt een beetje, en je krijgt een Wikipedia-artikel over dat onderwerp, je veegt opnieuw, je krijgt een vertaaltool die het in andere talen of uit andere talen kan vertalen, en plotseling is je kennis van de taal zo veel rijker, en het gebeurt gewoon een verbazingwekkend aantal keren, vergeleken met wanneer je moest gaan en trek die bron voor jezelf.
En dus ga ik betogen dat de workflow voor een analist en de manier waarop een analist met gegevensdocumentatie omgaat, in feite erg lijkt op hoe een lezer zal omgaan met het woordenboek, of het nu fysiek is, of hoewel de Kindle, en wat wij, de manier waarop we deze productiviteitsverhoging echt zagen, is niet de catalogus morsen, maar deze verbinden met de workflow van de analist, en dus hebben ze me gevraagd om een demo hier te doen, en ik wil om dat de focus van deze presentatie te maken. Maar ik wil alleen de context voor de demo instellen. Als we erover nadenken de gegevenskennis naar de gebruikers te sturen wanneer ze deze nodig hebben, denken we dat de juiste plaats om dat te doen, de plaats waar ze hun tijd doorbrengen en waar ze de analyse uitvoeren, een SQL-querytool is. Een plaats waar u SQL-query's schrijft en uitvoert. En dus hebben we er een gebouwd, en we hebben het gebouwd, en het ding dat er echt anders aan is dan andere querytools, is de diepe integratie met de gegevenscatalogus.
Dus onze query-tool heet Alation Compose. Het is een webgebaseerd hulpprogramma voor zoekopdrachten en ik zal het u zo meteen laten zien. Een webgebaseerd queryhulpprogramma dat werkt met al die database-logo's die u op de vorige dia zag. Wat ik in het bijzonder ga proberen te demonstreren, is de manier waarop de catalogusinformatie naar gebruikers komt. En dit gebeurt op drie verschillende manieren. Het doet het door middel van interventies, en dat is waar iemand die een gegevensbeheerder is, of een gegevensbeheerder, of een soort beheerder op de een of andere manier, of een manager, kan zeggen: "Ik wil een soort tussenwerpsel plaatsen met een notitie of een waarschuwing in de workflow en zorg ervoor dat deze op het juiste moment bij gebruikers wordt afgeleverd. ”Dus dat is een interventie en dat zullen we laten zien.
Slimme suggesties is een manier waarop de tool alle geaggregeerde kennis van de catalogus gebruikt om objecten en delen van een query voor te stellen terwijl u deze schrijft. Het belangrijkste om te weten is dat het echt gebruikmaakt van het querylogboek om dat te doen, om dingen te suggereren op basis van gebruik en om zelfs delen van vragen te vinden die eerder zijn geschreven. En dat zullen we laten zien.
En vervolgens voorbeelden. Voorvertoningen zijn, terwijl u de naam van een object typt, laten we u alles zien wat de catalogus weet, of op zijn minst de meest relevante dingen die de catalogus over dat object weet. Dus steekproeven van de gegevens, die het eerder hadden gebruikt, de logische naam en beschrijving van dat object, komen allemaal naar je toe terwijl je het schrijft zonder erom te hoeven vragen.
Dus zonder meer te praten, ga ik naar de demo en wacht ik gewoon totdat het verschijnt. Wat ik je hier ga laten zien, is het hulpprogramma voor zoekopdrachten. Het is een speciale SQL-schrijfinterface. Het is in zekere zin een afzonderlijke interface van de catalogus. Dez en Robin spraken over de catalogus, en ik spring een beetje over de catalogusinterface, direct naar hoe deze rechtstreeks wordt ingevoerd om de workflow te bedienen.
Ik laat hier alleen een plaats zien waar ik SQL kan typen, en onderaan zie je dat er soort informatie verschijnt over de objecten waarnaar we verwijzen. Dus ik ga gewoon beginnen met het typen van een zoekopdracht en ik stop wanneer ik een van deze interventies krijg. Dus ik typ 'select' en ik wil het jaar. Ik wil de naam. En ik ga wat salarisgegevens opzoeken. Dus dit is een onderwijsdataset. Het heeft informatie over instellingen voor hoger onderwijs en ik kijk naar het gemiddelde facultaire salaris dat in een van deze tabellen staat.
Dus ik heb eigenlijk het woord 'salaris' getypt. Het staat niet precies in de naam van de kolom op die manier. We gebruiken zowel de logische metadata als de fysieke metadata om suggesties te doen. En waar ik hier op wil wijzen, is dit gele vak dat hier verschijnt. Er staat een waarschuwing in deze kolom. Ik ben daar niet naar op zoek gegaan, ik heb geen les gevolgd over hoe deze gegevens correct te gebruiken. Het kwam bij mij op en het is een waarschuwing over een vertrouwelijkheidsovereenkomst die met deze gegevens te maken heeft. Er zijn dus enkele openbaarmakingsregels. Als ik deze gegevens ga opvragen, ga ik gegevens uit deze tabel halen, ik moet voorzichtig zijn met hoe ik deze openbaar maak. Dus je hebt hier een governancebeleid. Er zijn enkele compliance-uitdagingen die het zo veel gemakkelijker maken om aan dit beleid te voldoen als ik ervan op de hoogte ben op het moment dat ik de gegevens bekijk.
Dus ik heb dat in me opkomen, en dan ga ik ook naar collegegeld kijken. En hier zien we de previews in het spel komen. Ik zie op deze collegezuil - er staat een collegezuil op de instellingslijst en ik zie daar een profiel van. Alation gaat en haalt voorbeeldgegevens uit de tabellen, en in dit geval toont het me iets dat behoorlijk interessant is. Het laat me de verdeling van de waarden zien, en het laat me zien dat de nulwaarde 45 keer in de steekproef verscheen, en meer dan elke andere waarde. Dus ik heb het gevoel dat we misschien wat gegevens missen.
Als ik een geavanceerd analist ben, is dit misschien al onderdeel van mijn workflow. Vooral als ik een bijzonder nauwgezette ben, waar ik van tevoren een hoop profileringsvragen zou doen. Wanneer ik een nieuw stuk gegevens nader, denk ik altijd na over wat onze gegevensdekking is. Maar als ik nieuw ben in gegevensanalyse, als ik nieuw ben in deze gegevensset, zou ik kunnen aannemen dat als er een kolom is, deze altijd wordt ingevuld. Of ik neem aan dat als het niet is ingevuld, het niet nul is, het is null of zoiets. Maar in dit geval hebben we veel nullen, en als ik een gemiddelde zou doen, zouden ze waarschijnlijk verkeerd zijn, als ik maar aannam dat die nullen eigenlijk nul waren in plaats van gegevens te missen.
Maar Alation vraagt je, door deze preview in je workflow te plaatsen, een beetje naar deze informatie te kijken en geeft zelfs een soort van beginnende analisten de kans om te zien dat er hier iets te merken valt aan die gegevens. Dus we hebben die preview.
Het volgende dat ik ga doen, is proberen te achterhalen uit welke tabellen deze informatie komt. Dus hier zien we de slimme suggesties. Het is altijd al geweest, maar met name hier heb ik niet eens iets getypt, maar het zal me voorstellen welke tabellen ik misschien zou willen gebruiken voor deze zoekopdracht. En het belangrijkste dat u hierover moet weten, is dat het profiteert van de gebruiksstatistieken. Dus in een omgeving zoals bijvoorbeeld eBay, waar je honderdduizenden tabellen in een enkele database hebt, met een tool die de tarwe van het kaf kan raken, en die gebruiksstatistieken gebruiken, is echt belangrijk voor het maken van deze suggesties waard iets.
Dus het gaat deze tabel voorstellen. Wanneer ik naar het voorbeeld kijk, markeren we eigenlijk drie van de kolommen die ik al in mijn zoekopdracht heb genoemd. Dus ik weet dat het er drie heeft, maar het heeft niet de naam. Ik moet de naam krijgen, dus ik ga meedoen. Wanneer ik een join doe, heb ik nu weer deze previews om me te helpen vinden, waar is de tabel met de naam. Dus ik zie dat deze een mooi opgemaakte, soort goed gekapitaliseerde naam heeft. Het lijkt één rij te hebben met een naam voor elke instelling, dus dat ga ik pakken, en nu heb ik een join-voorwaarde nodig.
En dus, wat Alation hier doet, is opnieuw terugkijken op de querylogboeken, eerdere keren zien dat deze twee tabellen zijn samengevoegd en verschillende manieren voorstellen om ze samen te voegen. Nogmaals, er is een interventie. Als ik naar een van deze kijk, heeft het een waarschuwing die me laat zien dat dit alleen moet worden gebruikt voor geaggregeerde analyse. Het zal waarschijnlijk het verkeerde produceren als je iets per instelling probeert te doen. Terwijl deze, met de OPE ID, wordt goedgekeurd als de juiste manier om aan deze twee tabellen deel te nemen als u gegevens op universitair niveau wilt. Dus ik doe dat, en het is een korte vraag, maar ik heb mijn vraag geschreven zonder echt noodzakelijkerwijs enig inzicht te hebben in wat de gegevens zijn. Ik heb nog nooit een ER-diagram van deze gegevensset bekeken, maar ik weet al heel veel over deze gegevens omdat de relevante informatie naar me toekomt.
Dat zijn dus de drie manieren waarop een catalogus, via een geïntegreerde query-tool, direct invloed kan hebben op de workflow terwijl u query's schrijft. Maar een van de andere voordelen van het integreren van een query-tool in een catalogus is dat ik, wanneer ik mijn vraag afrond en deze opsla, een titel kan plaatsen zoals "Instelling Collegegeld en Facultair salaris", en dan heb ik hier een knop die staat me toe het gewoon in de catalogus te publiceren. Het wordt heel gemakkelijk voor mij om dit terug te geven. Zelfs als ik het niet publiceer, wordt het vastgelegd als onderdeel van het querylogboek, maar wanneer ik het publiceer, wordt het feitelijk een deel van de manier waarop de gecentraliseerde plaats waar alle gegevenskennis leeft.
Dus als ik op Zoeken naar alle zoekopdrachten in Alation klik, word ik meegenomen - en hier zie je wat meer van de catalogusinterface - ik ga naar een specifieke zoekopdracht die me een manier laat zien om zoekopdrachten te vinden in heel de hele organisatie. En je ziet dat mijn nieuw gepubliceerde zoekopdracht bovenaan staat. En sommigen zullen hier misschien opmerken, terwijl we de vragen vastleggen, we ook de auteurs vastleggen, en we vestigen deze relatie tussen mij als auteur en deze gegevensobjecten waar ik nu iets over weet. En ik word gevestigd als een expert op deze vraag en op deze data-objecten. Dat is echt handig als mensen gegevens moeten leren kennen, en vervolgens de juiste persoon kunnen vinden om te leren. En als ik echt nieuw ben in data, of ik nu een geavanceerd analist ben - als een geavanceerd analist, zou ik dit kunnen bekijken en een aantal voorbeelden kunnen zien die me op weg zouden helpen met een nieuwe dataset. Als iemand die zich misschien niet superwijs voelt met SQL, kan ik vooraf gemaakte vragen vinden die rapporten zijn waar ik gebruik van kan maken.
Hier is er een van Phil Mazanett over gemiddelde SAT-scores. Klik hierop en ik krijg een soort cataloguspagina voor de zoekopdracht zelf. Het gaat over een artikel dat is geschreven dat naar deze zoekopdracht verwijst, dus er is wat documentatie die ik kan lezen als ik wil leren hoe het te gebruiken. En ik kan het openen in de querytool door op de knop Opstellen te klikken, en ik kan het hier zelf uitvoeren zonder het te bewerken. En eigenlijk krijgt u een klein beetje van onze lichtgewicht rapportagemogelijkheden te zien, waar u, wanneer u een query schrijft, een sjabloonvariabele zoals deze kunt invoeren en het een eenvoudige manier creëert om een formulier te maken om een query uit te voeren op basis van op een paar parameters.
Dus dat heb ik voor de demo. Ik ga terug naar de dia's. Om het kort samen te vatten, we hebben laten zien hoe een beheerder, een gegevensregelaar, kan interveniëren door waarschuwingen te plaatsen op objecten die in de querytool worden weergegeven, hoe Alation zijn kennis van het gebruik van gegevensobjecten gebruikt om slimme suggesties te doen, hoe het brengt in profilering en andere tips om de workflows van analisten te verbeteren wanneer ze bepaalde objecten aanraken, en hoe al dat soort feeds teruggaan in de catalogus wanneer nieuwe vragen worden geschreven.
Uiteraard ben ik een woordvoerder namens het bedrijf. Ik ga leuke dingen zeggen over datacatalogi. Als je rechtstreeks van een van onze klanten wilt horen, runt Kristie Allen bij Safeway een team van analisten en heeft een heel cool verhaal over een tijd waarin ze echt de klok moest verslaan om een marketingexperiment af te leveren, en hoe haar hele team gebruikte Alation om samen te werken en zich heel snel om te draaien aan dat project. Dus u kunt deze bit.ly-link volgen om dat verhaal te bekijken, of als u een beetje wilt horen hoe Alation een datacatalogus in uw organisatie zou kunnen brengen, we zijn blij om een gepersonaliseerde demo op te zetten. Hartelijk bedankt.
Rebecca Jozwiak: Heel erg bedankt David. Ik weet zeker dat Dez en Robin een paar vragen hebben voordat ik overga naar de vragen en antwoorden van het publiek. Dez, wil je eerst gaan?
Dez Blanchfield: Absoluut. Ik ben dol op het idee van dit concept van gepubliceerde zoekopdrachten en het terug te koppelen aan de bron van het schrijven. Ik ben al lang kampioen van dit idee van een in-house app store en ik denk dat dit echt een geweldige basis is om daarop voort te bouwen.
Ik kreeg een beetje inzicht in sommige van de organisaties die je dit ziet doen, en een aantal van de succesverhalen die ze mogelijk hadden gehad tijdens deze hele reis om niet alleen je tool en platform te gebruiken om de gegevens te ontdekken, maar transformeer vervolgens ook hun interne culturele en gedragskenmerken. Nu hebben ze dit soort in-house app store waar je ze gewoon kunt downloaden, het concept waar ze het niet alleen kunnen vinden, maar ze kunnen zelfs beginnen met het ontwikkelen van kleine communities met de beheerders van die kennis.
David Crawford: Ja, ik denk dat we verrast zijn. We geloven in de waarde van het delen van vragen, zowel uit mijn verleden als productmanager in Adtech als van alle klanten waarmee we hebben gesproken, maar ik ben nog steeds verbaasd over hoe vaak het een van de eerste dingen is die klanten praten over de waarde die ze uit Alation halen.
Ik was bezig met het testen van de gebruiker van de querytool bij een van onze klanten genaamd Invoice2go, en ze hadden een productmanager die relatief nieuw was, en ze zeiden - hij vertelde me eigenlijk, ongevraagd tijdens de gebruikerstest: "Ik zou eigenlijk niet schrijf helemaal SQL behalve dat het gemakkelijk wordt gemaakt door Alation. "En natuurlijk, als de premier, ga ik een beetje:" Wat bedoel je, hoe hebben we dat gedaan? "En hij zei:" Wel, eigenlijk is het gewoon omdat ik kan inloggen en ik al deze bestaande query's kan zien. ”Beginnen met een lege lei met SQL is een ongelooflijk moeilijk iets om te doen, maar het wijzigen van een bestaande query waarbij u het resultaat kunt zien dat wordt weergegeven en u kunt zeggen, "Oh, ik heb alleen deze extra kolom nodig, " of "ik moet het filteren op een bepaald datumbereik", dat is een veel eenvoudiger ding om te doen.
We hebben dergelijke nevenrollen gezien, zoals productmanagers, misschien mensen in verkoopmedewerkers, die beginnen op te pakken, en die altijd al SQL wilden leren en beginnen op te pakken met behulp van deze catalogus. We hebben ook gezien dat veel bedrijven hebben geprobeerd een soort open source te doen. Ik heb geprobeerd dit soort dingen intern te bouwen, waar ze de vragen volgen en beschikbaar stellen, en er zijn een aantal echt lastige ontwerpuitdagingen om ze nuttig te maken. Facebook heeft een interne tool gehad die ze HiPal noemden, waarmee alle op Hive geschreven vragen werden vastgelegd, maar wat je erachter komt is dat als je de gebruikers niet op de juiste manier een duwtje geeft, je gewoon eindigt met een zeer lange lijst met selecte verklaringen. En als een gebruiker die probeert te achterhalen of een vraag nuttig voor mij is of als het goed is, als ik gewoon door een lange lijst met selecte verklaringen ga kijken, zal het me veel meer tijd kosten om daar iets waardevols te krijgen dan beginnen bij het begin. We hebben goed nagedacht over het maken van een querycatalogus die de juiste dingen naar voren haalt en op een handige manier biedt.
Dez Blanchfield: Ik denk dat we allemaal op heel veel manieren deze reis doormaken vanaf een zeer jonge leeftijd tot volwassenheid. Een heleboel technologieën. Ik, persoonlijk, ik heb datzelfde echte echte ding meegemaakt, zoals het leren knippen van code. Ik ging door tijdschriften en vervolgens boeken, en ik zou studeren tot een bepaald niveau, en dan moest ik gaan en er daadwerkelijk wat meer training en opleiding op volgen.
Maar per ongeluk ontdekte ik dat zelfs toen ik mezelf ging lesgeven en tijdschriften en boeken las en programma's van andere mensen hakte en er cursussen op volgde, ik nog steeds net zoveel leerde van het volgen van de cursussen als dat ik gewoon met andere praatte mensen die enkele ervaringen hadden. En ik denk dat het een interessante ontdekking is dat, nu je dat naar data-analyse brengt, we in feite diezelfde parallel zien, dat mensen steevast behoorlijk slim zijn.
Het andere dat ik heel graag wil begrijpen, is dat op een zeer hoog niveau veel organisaties vragen: "Hoe lang duurt het om op dat punt te geraken?" Wat is het kantelpunt in de tijd als mensen krijgen uw platform geïnstalleerd en begonnen ze de soorten tools te ontdekken? Hoe snel zien mensen dit ding gewoon een echt onmiddellijk 'a-ha'-moment zien worden waar ze zich realiseren dat ze zich niet eens meer zorgen maken over de ROI omdat het er is, maar nu veranderen ze eigenlijk de manier waarop ze zaken doen ? En ze hebben een verloren kunst ontdekt en ze verwachten dat ze er iets heel, heel leuks mee kunnen doen.
David Crawford: Ja, ik kan er een beetje op ingaan. Ik denk dat als we geïnstalleerd worden, dat een van de leuke dingen, een van de dingen die mensen leuk vinden aan een catalogus die rechtstreeks is verbonden met de gegevenssystemen, is dat je niet leeg begint waar je het soort moet invullen pagina voor pagina. En dit geldt min of meer voor eerdere gegevensoplossingen waar je zou beginnen met een lege tool en je moet beginnen met het maken van een pagina voor alles wat je wilt documenteren.
Omdat we zoveel dingen automatisch documenteren door de metagegevens te extraheren, in wezen binnen enkele dagen nadat de software is geïnstalleerd, kunt u een afbeelding van uw gegevensomgeving hebben die ten minste 80 procent in de tool heeft. En dan denk ik dat zodra mensen beginnen met het schrijven van vragen met de tool, ze automatisch worden opgeslagen in de catalogus, en dus zullen ze ook verschijnen.
Ik wil niet te enthousiast zijn om het te zeggen. Ik denk dat twee weken een redelijk goede conservatieve schatting is voor een maand. Twee weken tot een maand, conservatieve schatting van echt omdraaien en het gevoel hebben dat je er waarde uit haalt, alsof je wat kennis begint te delen en in staat bent om daarheen te gaan en dingen over je gegevens te ontdekken.
Dez Blanchfield: Het is echt verbazingwekkend als je erover nadenkt. Het feit dat sommige van de grote dataplatforms die u effectief indexeert en catalogiseert, soms tot een jaar zal duren om te implementeren en te implementeren en op te staan.
De laatste vraag die ik voor je heb voordat ik het aan Robin Bloor geef, zijn connectoren. Een van de dingen die meteen naar me springt, is dat je die hele uitdaging duidelijk hebt opgelost. Er zijn dus een paar vragen gewoon heel snel. Ten eerste, hoe snel worden connectoren geïmplementeerd? Uiteraard begin je met het grootste platform, zoals de Oracles en de Teradatas enzovoort en DB2s. Maar hoe regelmatig zie je nieuwe connectoren doorkomen, en hoe lang duren ze? Ik stel me voor dat je een standaard framework voor ze hebt. En hoe diep ga je daar in? Bijvoorbeeld de Oracles en IBM's van de wereld, en zelfs Tereadata, en dan enkele van de meest populaire van late open-source platforms. Werken ze rechtstreeks met u samen? Ontdek je het zelf? Moet je voorkennis hebben op die platforms?
Hoe ziet het eruit om een connector te ontwikkelen, en hoe diep raak je betrokken bij die partnerschappen om ervoor te zorgen dat die connectoren alles ontdekken wat je kunt?
David Crawford: Ja, natuurlijk, het is een geweldige vraag. Ik denk dat we de connectoren grotendeels kunnen ontwikkelen. Dat deden we zeker toen we een jongere startup waren en geen klanten hadden. We kunnen de verbindingen zeker ontwikkelen zonder interne toegang. We krijgen nooit speciale toegang tot de gegevenssystemen die niet openbaar beschikbaar zijn, en vaak zonder dat we voorkennis nodig hebben. We maken gebruik van de metadataservices die door de datasystemen zelf beschikbaar zijn. Vaak zijn die behoorlijk complex en moeilijk om mee te werken. Ik ken vooral SQL Server, de manier waarop ze het querylog beheren, er zijn verschillende configuraties en daar moet je echt aan werken. Je moet de nuances en de knoppen en draaiknoppen erop begrijpen om het goed in te stellen, en dat is iets waar we met klanten aan werken, omdat we het al verschillende keren eerder hebben gedaan.
Maar tot op zekere hoogte zijn het soort openbare API's die beschikbaar zijn of openbare interfaces die beschikbaar zijn die we benutten. We hebben partnerschappen met verschillende van deze bedrijven, dat is meestal een reden voor certificering, zodat ze zich gerust voelen dat we werken en ze kunnen ons ook middelen bieden om te testen, soms vroege toegang tot een platform dat naar buiten komt om ervoor te zorgen dat we werken aan de nieuwe versies.
Om een nieuwe connectie te maken, zou ik nogmaals zeggen, in een poging conservatief te zijn, laten we zeggen zes weken tot twee maanden. Het hangt ervan af hoe vergelijkbaar het is. Sommige werken van Postgre lijken dus erg op Roodverschuiving. Redshift en Vertica delen veel van hun details. Dus we kunnen profiteren van die dingen. Maar ja, zes weken tot twee maanden zou eerlijk zijn.
We hebben ook API's, dus - we beschouwen Alation ook als een metadataplatform, dus als er niets is dat we kunnen bereiken en automatisch kunnen pakken, zijn er manieren waarop u de connector zelf kunt schrijven en in ons systeem kunt duwen, zodat dat alles nog steeds wordt gecentraliseerd in een enkele zoekmachine.
Dez Blanchfield: Fantastisch. Dat waardeer ik. Dus we gaan het overhandigen aan Robin, want ik weet zeker dat hij ook een overvloed aan vragen heeft. Robin?
Rebecca Jozwiak: Robin is mogelijk gedempt.
Dez Blanchfield: Je hebt jezelf gedempt.
Robin Bloor: Ja, toch. Sorry, ik heb mezelf gedempt. Wat is het proces wanneer u dit implementeert? Ik ben een beetje nieuwsgierig omdat er op veel plaatsen veel gegevens kunnen zijn. Hoe gaat dat in zijn werk?
David Crawford: Ja, natuurlijk. We gaan naar binnen, eerst is het een soort IT-proces om ervoor te zorgen dat onze server is ingericht, ervoor te zorgen dat netwerkverbindingen beschikbaar zijn, dat de poorten open zijn zodat we daadwerkelijk toegang hebben tot de systemen. Ze weten allemaal vaak met welke systemen ze willen beginnen. Weten in een gegevenssysteem, en soms helpen we hen ook. We helpen ze om een eerste blik te werpen op hun querylogboek om te begrijpen wie wat gebruikt en hoeveel gebruikers ze op een systeem hebben. Dus we zullen helpen erachter te komen waar - ze, vaak, als ze honderden of duizenden mensen hebben die zich mogelijk aanmelden bij databases, ze eigenlijk niet weten waar ze inloggen, dus we kunnen erachter komen van de Query logt hoeveel unieke gebruikersaccounts u daadwerkelijk heeft ingelogd en hier queries uitvoert in een maand of zo.
Daar kunnen we dus gebruik van maken, maar vaak alleen van de belangrijkste. We zetten ze op en er is een proces van zeggen: "Laten we prioriteiten stellen." Er is een scala aan activiteiten die parallel kunnen gebeuren. Ik zou me concentreren op de training voor het gebruik van de querytool. Als mensen eenmaal de query-tool beginnen te gebruiken, zijn veel mensen dol op het feit dat het slechts een enkele interface is voor al hun verschillende systemen. Ze houden ook van het feit dat het webgebaseerd is, geen installaties vereist als ze dat niet willen. Vanuit een beveiligingsstandpunt houden ze ervan een soort van een enkel toegangspunt te hebben, vanuit een netwerkstandpunt, tussen een soort van een corp IT-netwerk en het datacenter waar de productiegegevensbronnen wonen. En dus zullen ze Alation instellen als een query-tool en Compose gaan gebruiken als toegangspunt voor al deze systemen.
Dus zodra dat gebeurt, richten we ons op training op het begrijpen van enkele van de verschillen tussen een webgebaseerde of servergebaseerde querytool versus een die u op uw bureaublad zou hebben, en enkele nuances van het gebruik van dat. En tegelijkertijd proberen we de meest waardevolle gegevens te identificeren, opnieuw gebruik te maken van de gegevens van het querylogboek en te zeggen: "Hé, misschien wilt u naar binnen gaan en mensen helpen deze te begrijpen. Laten we beginnen met het publiceren van representatieve vragen over deze tabellen. ”Dat is soms de meest effectieve manier om mensen snel op te vrolijken. Laten we eens kijken naar uw eigen querygeschiedenis, deze dingen publiceren zodat ze worden weergegeven als de eerste query's. Wanneer mensen naar een tabelpagina kijken, kunnen ze alle vragen zien die die tabel hebben geraakt en kunnen ze vanaf daar beginnen. En laten we vervolgens titels en beschrijvingen aan deze objecten toevoegen, zodat ze gemakkelijker te vinden en te doorzoeken zijn, zodat u enkele van de nuances kent van het gebruik ervan.
We zorgen ervoor dat we het querylogboek grondig bekijken, zodat we afkomst kunnen genereren. Een van de dingen die we doen, is dat we door het querylogboek kijken op het moment dat gegevens van de ene naar de andere tabel worden verplaatst, en dat stelt ons in staat om een van de meest gestelde vragen over een gegevenstabel te stellen, waar kwam dit vandaan? Hoe vertrouw ik erop? En dus kunnen we niet alleen laten zien uit welke andere tabellen het kwam, maar hoe het onderweg werd getransformeerd. Nogmaals, dit wordt mogelijk gemaakt door het querylogboek.
Dus we zorgen ervoor dat die dingen zijn ingesteld en dat we afkomst krijgen in het systeem, en we richten ons op de meest waardevolle en meest waardevolle stukken metadata die we op de tabelpagina's kunnen vestigen, zodat wanneer u zoekt, vindt u iets nuttigs.
Robin Bloor: Oké. De andere vraag - er zijn veel vragen uit het publiek, dus ik wil hier niet te veel tijd in beslag nemen - de andere vraag die me te binnen schiet is alleen de pijnpunten. Veel software is gekocht omdat mensen op de een of andere manier problemen hebben met iets. Dus wat is het gemeenschappelijke pijnpunt dat mensen naar Alation leidt?
David Crawford: Ja. Ik denk dat er een paar zijn, maar ik denk dat een van de voorbeelden die we vrij vaak horen, het inwerken van analisten is. "Ik ga op de korte termijn 10, 20, 30 mensen inhuren die nieuwe inzichten uit deze gegevens moeten produceren, hoe komen ze op snelheid?" Dus onboarding van analisten is iets dat we zeker weten Onderscheppen. Er is ook gewoon de senior analisten ontslagen van het besteden van al hun tijd aan het beantwoorden van vragen van andere mensen over data. Dat komt ook heel vaak voor. En beide zijn in wezen onderwijsproblemen.
En dan zou ik zeggen dat een andere plek waar mensen Alation zien, is wanneer ze een geheel nieuwe gegevensomgeving willen opzetten voor iemand om in te werken. Ze willen dit intern adverteren en op de markt brengen waar mensen gebruik van kunnen maken. Dan is het erg aantrekkelijk om van Alation de front-end te maken voor die nieuwe analytische omgeving. Het heeft de documentatie, het heeft een enkel toegangspunt tot de - een enkel toegangspunt tot de systemen, en dus is dat een andere plaats waar mensen naar ons toe komen.
Robin Bloor: Oké, ik zal je doorgeven aan Rebecca omdat het publiek je probeert te bereiken.
Rebecca Jozwiak: Ja, we hebben hier veel echt goede publieksvragen. En David, deze werd specifiek aan jou gesteld. Het is van iemand die blijkbaar enige ervaring heeft met mensen die vragen verkeerd gebruiken, en hij zegt eigenlijk dat hoe meer we gebruikers machtigen, hoe moeilijker het is om verantwoord gebruik van rekenbronnen te regelen. Dus kunt u zich verdedigen tegen de verspreiding van misleide maar veel voorkomende zoektermen?
David Crawford: Ja, ik zie deze vraag. Het is een geweldige vraag - een vraag die we vrij vaak krijgen. Ik heb zelf de pijn gezien bij vorige bedrijven, waar je gebruikers moet trainen. Bijvoorbeeld: “Dit is een logboektabel, het heeft logboeken die al jaren teruggaan. Als je een vraag over deze tafel gaat schrijven, moet je je echt beperken tot de datum. ”Dus dat is bijvoorbeeld een training die ik bij een vorig bedrijf heb gevolgd voordat ik toegang kreeg tot de database.
We hebben een aantal manieren waarop we dit proberen aan te pakken. Ik zou zeggen dat ik denk dat loggegevens van zoekopdrachten echt uniek zijn om ze aan te pakken. Het geeft een ander inzicht versus wat de database intern doet met zijn queryplanner. En wat we doen is een van die interventies - we hebben de handmatige interventies die ik heb laten zien, en dat is handig, toch? Dus bij een bepaalde join kun je bijvoorbeeld zeggen: "Laten we dit afschaffen." Het zal een grote rode vlag hebben wanneer het verschijnt in slimme suggestie. Dus dat is een manier om mensen te bereiken.
Een ander ding dat we doen is, geautomatiseerd bij interventies tijdens uitvoeringstijd. Dat zal eigenlijk de parse-boom van de query gebruiken voordat we het uitvoeren om te zien, bevat het een bepaald filter of een paar andere dingen die we daar ook doen. Maar een van de meest waardevolle en de eenvoudigste om uit te leggen is, bevat het een filter? Dus net als dat voorbeeld dat ik zojuist gaf, moet deze logboektabel, als je ernaar wilt zoeken, een datumbereik hebben, je kunt op de tabelpagina opgeven dat je dat datumbereikfilter verplicht moet worden toegepast. Als iemand een query probeert uit te voeren die dat filter niet bevat, stopt het hem eigenlijk met een grote waarschuwing en staat er: "U moet waarschijnlijk een aantal SQL toevoegen die er zo uitziet aan uw query." Ze kunnen doorgaan als zij willen. We gaan ze niet volledig verbieden om het te gebruiken - het is ook een zoekopdracht, het moet aan het einde van de dag zoekopdrachten uitvoeren. Maar we plaatsen een vrij grote barrière voor hen en we geven hen een suggestie, een concreet toepasbare suggestie om de query te wijzigen om hun prestaties te verbeteren.
In sommige gevallen doen we dat ook automatisch, opnieuw door het querylogboek te observeren. Als we zien dat een heel groot percentage van de zoekopdrachten in deze tabel gebruik maakt van een bepaald filter of een bepaalde join-clausule, zullen we dat in feite opduiken. We zullen dat promoten tot een interventie. Eigenlijk gebeurde het mij op een interne dataset. We hebben klantgegevens en we hebben gebruikers-ID's, maar de ingestelde gebruikers-ID, omdat het een soort is - we hebben gebruikers-ID's bij elke klant. Het is niet uniek, dus je moet het koppelen aan een klant-ID om een unieke join-sleutel te krijgen. En ik was een vraag aan het schrijven en ik probeerde iets te analyseren en het dook op en zei: "Hé, iedereen lijkt zich bij deze tabellen aan te sluiten met zowel de klant-ID als de gebruikers-ID. Weet je zeker dat je dat niet wilt doen? 'En het weerhield me er eigenlijk van om een verkeerde analyse te maken. Het werkt dus zowel voor de nauwkeurigheid van de analyse als voor de prestaties. Dus dat is een soort van hoe we dat probleem aanpakken.
Rebecca Jozwiak: Dat lijkt mij effectief. Je zei dat je mensen niet noodzakelijkerwijs zult blokkeren van het verzamelen van middelen, maar ze een beetje leert dat wat ze doen misschien niet de beste is, toch?
David Crawford: We gaan er altijd van uit dat de gebruikers niet kwaadaardig zijn - geef ze de beste bedoelingen - en we proberen op die manier behoorlijk open te zijn.
Rebecca Jozwiak: Oké. Hier is nog een vraag: “Wat is het verschil tussen een catalogusbeheerder, zoals bij uw oplossing, en een MDM-tool? Of vertrouwt het feitelijk op een ander principe door de keuze van de query-tabellen te verruimen, terwijl MDM het automatisch zou doen, maar met hetzelfde onderliggende principe van het verzamelen van metadata. "
David Crawford: Ja, ik denk dat als ik naar traditionele MDM-oplossingen kijk, het belangrijkste verschil een filosofisch verschil is. Het draait allemaal om wie de gebruiker is. Zoiets als ik zei aan het begin van mijn presentatie, Alation, ik denk dat we bij onze oprichting zijn opgericht met als doel om analisten in staat te stellen meer inzichten te produceren, ze sneller te produceren, om nauwkeuriger te zijn in de inzichten die zij produceren. Ik denk niet dat dat ooit het doel is geweest van een traditionele MDM-oplossing. Die oplossingen zijn meestal gericht op mensen die rapporten moeten produceren over welke gegevens zijn vastgelegd in de SCC of intern voor een ander soort controledoeleinden. Het kan soms analisten inschakelen, maar vaker, als het een beoefenaar in zijn werk gaat inschakelen, is het waarschijnlijker dat een data-architect zoals een DBA wordt ingeschakeld.
Wanneer u vanuit het standpunt van een analist over dingen nadenkt, begint u met het bouwen van een query-tool die een MDM-tool nooit zou doen. Op dat moment begin je na te denken over prestaties en nauwkeurigheid, en begrijp je ook welke gegevens verband houden met mijn zakelijke behoefte. Al die dingen zijn dingen die in ons hoofd opduiken wanneer we de tool ontwerpen. Het gaat in op onze zoekalgoritmen, het gaat in op de lay-out van de cataloguspagina's en de mogelijkheid om kennis uit de hele organisatie bij te dragen. Het gaat erom dat we de query-tool hebben gebouwd en dat we de catalogus er rechtstreeks in hebben gebouwd, dus ik denk dat het daar echt van komt. Welke gebruiker heeft u als eerste in gedachten?
Rebecca Jozwiak: Oké, goed. Dat hielp echt om het uit te leggen. die zo graag de archieven wilde pakken omdat hij moest vertrekken, maar hij wilde echt dat zijn vraag beantwoord zou worden. Hij zei dat het in het begin werd vermeld dat er meerdere talen zijn, maar is SQL de enige taal die binnen de Compose-component wordt gebruikt?
David Crawford: Ja, dat is waar. En een van de dingen die mij zijn opgevallen, zoals ik de explosie van de verschillende soorten databases, van documentdatabases, van grafische databases, van key value-winkels heb gezien, is dat ze echt krachtig zijn voor applicatie-ontwikkelingen. Ze kunnen daar heel goed in specifieke behoeften voorzien, op betere manieren dan relationele databases.
Maar wanneer u het terugbrengt naar gegevensanalyse, wanneer u het terugbrengt naar - wanneer u die informatie wilt verstrekken aan mensen die ad-hocrapportage gaan doen of ad hoc in de gegevens gaan graven, dat ze altijd terugkomen op een relationele, tenminste, interface voor de mens. Dat komt deels omdat SQL de lingua franca van data-analyse is, dus dat betekent voor de mens ook voor de tools die integreren. Ik denk dat dit de reden is dat SQL op Hadoop zo populair is en dat er zoveel pogingen zijn om het op te lossen, omdat mensen dat uiteindelijk weten. Er zijn waarschijnlijk miljoenen mensen die weten hoe ze SQL moeten schrijven, en ik zou niet miljoenen mensen wagen die weten hoe ze een Mongo-aggregatie pipeline framework query moeten schrijven. En dat het een standaardtaal is die wordt gebruikt voor integratie op een heel breed scala aan platforms. Dus dat is alles, we worden zelden gevraagd om erbuiten te gaan, omdat dit de interface is die de meeste analisten gebruiken, en het is een plek waar we ons, vooral in Compose, hebben gericht op het schrijven van SQL.
Ik zou zeggen dat data science de plek is waar ze zich het meest buiten wagen, en daarom krijgen we af en toe vragen over het gebruik van Pig of SAS. Dit zijn dingen die we absoluut niet behandelen in Compose, en die we graag in de catalogus willen vastleggen. En ik zie ook R en Python. We hebben een aantal manieren waarop we interfaces hebben gemaakt waarmee u de query's kunt gebruiken die in Alation in R- en Python-scripts zijn geschreven, dus omdat u, als u een datawetenschapper bent en in een scripttaal werkt, uw brongegevens bevinden zich in een relationele database. Je begint met een SQL-query en verwerkt deze vervolgens verder en maakt grafieken binnen R en Python. En we hebben pakketten gemaakt die u kunt importeren in die scripts die de query's of de queryresultaten uit Alation halen, zodat u daar een soort gemengde workflow kunt hebben.
Rebecca Jozwiak: Oké, geweldig. Ik weet dat we een beetje voorbij de top van het uur zijn gelopen, ik ga gewoon nog een of twee vragen stellen. Ik weet dat je het hebt gehad over alle verschillende systemen waarmee je verbinding kunt maken, maar wat betreft extern gehoste gegevens en intern gehoste gegevens, kan dat samen worden doorzocht in je enkele weergave, in je ene platform?
David Crawford: Natuurlijk. Er zijn een paar manieren om dat te doen. Ik bedoel, extern gehost, zou ik me kunnen voorstellen, ik probeer na te denken over wat dat precies zou kunnen betekenen. Het kan een database zijn die iemand voor u in AWS host. Het kan een openbare gegevensbron van data.gov betekenen. We maken rechtstreeks verbinding met databases door in te loggen, net als een andere applicatie met, met een database-account, en dat is hoe we de metadata extraheren. Dus als we een account hebben en een open netwerkpoort hebben, kunnen we er naartoe gaan. En wanneer we die dingen niet hebben, hebben we iets dat een virtuele gegevensbron wordt genoemd, waarmee u in wezen documentatie kunt pushen, automatisch, door uw eigen connector te schrijven, of door het in te vullen door het te doen zoals een CSV-upload, om de gegevens naast uw interne gegevens te documenteren. Dat wordt allemaal in de zoekmachine geplaatst. Het wordt verwezen in artikelen en andere documentatie en gesprekken in het systeem. Dus dat is hoe we omgaan als we niet rechtstreeks verbinding kunnen maken met een systeem.
Rebecca Jozwiak: Oké, dat is logisch. Ik schiet nog een vraag voor je uit. Eén deelnemer is met de vraag: "Hoe moet de inhoud van een gegevenscatalogus worden gevalideerd, geverifieerd of onderhouden, aangezien brongegevens worden bijgewerkt, brongegevens worden gewijzigd, enz."
David Crawford: Ja, het is een vraag die we veel krijgen, en ik denk dat een van de dingen die we doen - een van onze filosofieën, zoals ik al zei, we geloven niet dat de gebruikers kwaadaardig zijn. We gaan ervan uit dat ze proberen de beste kennis bij te dragen. Ze zullen niet binnenkomen en mensen opzettelijk misleiden over de gegevens. Als dat een probleem is in uw organisatie, is Alation misschien niet de juiste tool voor u. Maar als u goede bedoelingen van de gebruikers aanneemt, dan beschouwen we het als iets waar de updates binnenkomen, en dan doen we meestal een rentmeester die verantwoordelijk is voor elk gegevensobject of elk gedeelte van de gegevens. En we kunnen die stewards op de hoogte brengen wanneer wijzigingen in de metagegevens worden aangebracht en ze kunnen het op die manier verwerken. Ze zien updates binnenkomen, ze valideren ze. Als ze niet gelijk hebben, kunnen ze teruggaan en ze aanpassen en informeren, en hopelijk zelfs de gebruiker bereiken die de informatie heeft bijgedragen en hen helpen leren.
Dus dat is de primaire manier waarop we erover nadenken. Dit soort suggesties van de menigte en het management van de stewards, dus daar hebben we wat mogelijkheden voor.
Rebecca Jozwiak: Oké, goed. En als je de mensen gewoon kunt laten weten hoe ze het beste aan de slag kunnen met Alation, en waar kunnen ze specifiek naartoe gaan voor meer informatie. Ik weet dat je dat een beetje hebt gedeeld .ly. Is dat de beste plaats?
David Crawford: Alation.com/learnmore Ik denk dat het een geweldige manier is om te gaan. Om u aan te melden voor een demo heeft de Alation.com-site veel geweldige bronnen, whitepapers voor klanten en nieuws over onze oplossing. Dus ik denk dat dat een geweldige plek is om te beginnen. U kunt ook e-mailen.
Rebecca Jozwiak: Oké, geweldig. En ik weet, aanwezigen, sorry als ik vandaag niet op alle vragen heb gereageerd, maar als dat niet zo is, zullen ze worden doorgestuurd naar David of zijn verkoopteam of iemand bij Alation, zodat ze zeker kunnen helpen uw vragen te beantwoorden en te helpen begrijpen wat Alation doet of waar ze het beste in zijn.
En daarmee, mensen, zal ik doorgaan en ons afmelden. U kunt de archieven altijd vinden op InsideAnalysis.com. Je kunt het ook vinden op Techopedia.com. Ze hebben de neiging om een beetje sneller te updaten, dus bekijk dat zeker. En dank aan David Crawford, Dez Blanchfield en Robin Boor vandaag. Het was een geweldige webcast. En daarmee zeg ik je vaarwel. Bedankt mensen. Tot ziens.
David Crawford: Bedankt.
