De kracht van suggestie: hoe een gegevenscatalogus analisten machtigt

Afhaal: Gastheer Rebecca Jozwiak bespreekt de voordelen van gegevenscatalogi 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 gekregen: "De kracht van suggestie: hoe een gegevenscatalogus analisten machtigt." Ik ben uw gastheer Rebecca Jozwiak, die vandaag onze gebruikelijke gastheer Eric Kavanagh invult, terwijl hij reist de wereld rond, 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, streaminggegevens, cloudacceptatie, Hadoop blijft volwassen en wordt geadopteerd. 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 rond te dwalen, als je gewoon wilde kijken, en zeker dat je misschien net iets leuks zou ontdekken, zou je misschien een aantal interessante feiten ontdekken die je niet wist, maar als je echt iets moest vinden, en je wist wat je zocht, je had de kaartcatalogus nodig, en natuurlijk is het enterprise-equivalent een gegevenscatalogus, die kan helpen licht te werpen op alle gegevens voor onze gebruikers om te verrijken, ontdekken, delen, consumeren en mensen echt te helpen krijgen om gegevens sneller en gemakkelijker te maken.

Dus vandaag hebben we Dez Blanchfield, onze eigen datawetenschapper, en we hebben dokter Robin Bloor, onze eigen hoofdanalist, we hebben David Crawford van Alation, die gaat praten over het verhaal van zijn bedrijfscatalogus, maar eerst gaan we om te 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 er in zit en hoe je er toegang toe kunt krijgen.

Ik weet misschien wel dat ik tientallen databases heb, maar ik weet eigenlijk niet wat er in zit of hoe ik erachter kan komen wat er in zit, en zo steevast als we nu ontdekken in de pre-show data, heb je de neiging om te lopen rond het kantoor en stel vragen, en schreeuw over de kubieke muren en probeer erachter te komen, vaak is mijn ervaring dat je misschien zelfs merkt dat je naar de receptie, de receptie loopt en vraagt ​​of iemand weet wie je bent ' ga 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 rond activa en nadelen en namen, en tenzij je dat project kent en je kent die persoon, kun je die informatie 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 wegwerp en dat is dat een bepaald aantal mensen denken dat gegevens de nieuwe olie zijn, en ik weet zeker dat we gaan we dat later ook vandaag bespreken. 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 de meeste van deze merken bedoel ik dat we Uber hebben, het grootste taxibedrijf ter wereld. Ze hebben 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 inventaris. , 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, daar zijn we 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 omgeving kunt komen - wanneer Netfix werd gelanceerd in Australië, het verhoogde de internationale bandbreedte op onze internetverbindingen met 40 procent, dus het verdubbelde bijna het internetgebruik in Australië 's nachts, 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 gegevens, en dat bedrijven hier wakker van worden. 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 in recordtijd een hoge marktwaarde hebben gewonnen 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 Heb je dat niet intern 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 de traditionele webpagina, of een bestandsserver.

In plaats van de volgende generatie datacatalogus op veel 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 . We kunnen die hele uitdaging niet langer leiden tot mensen die alleen maar notities doorgeven, notities posten en erover praten. We zijn nu echt voorbij het gebied waar deze next-gen benadering van gegevenscatalogus is gekomen en gegaan. We moeten er onze armen omheen slaan. Als dit een gemakkelijk 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 zit en metadata bouwen rondom wat we ontdekken en het vervolgens beschikbaar stellen in een gemakkelijke, consumeerbare vorm, met name voor self-service 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 gaan 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. Wat betekent dat we met een probleem van datatransport eindigen, en soms is er geen noodzaak voor datatransport, maar het is ook een moeilijkheid. 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. Er zijn tegenwoordig bijna altijd grenzen aan de hoeveelheid tijd die 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 meer een 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 het moet doen, omdat het kan niet zijn 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 kunt krijgen die u nodig hebt wanneer u daadwerkelijk voor de gegevens gaat en dat hangt af van con. Dus het is in ieder geval een moeilijke situatie. In termen van gegevensquery's, waren we in staat om te denken in termen van SQL, we komen nu echt naar boven, weet je, verschillende vormen van query's, SQL ja, maar aangrenzende, ook grafiekquery's, Spark is slechts een voorbeeld van het doen van grafiek , omdat we ook moeten zoeken, meer dan ooit tevoren, ook regex-type zoekopdrachten, wat echt gecompliceerde zoekopdrachten voor patronen is, en echte patroonvergelijking, 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 federatie van de een of andere soort 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 gewoon de moeite waard om erop te wijzen dat als u daadwerkelijk naar de prestaties van de analyse kijkt, de werkelijke 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 ​​niet voor niets, we zeggen tenminste dat, we weten, 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 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, u weet 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 veiligheid, veel aspecten van het gegevensbeheer, als je echt niet weet welke gegevens je hebt, het idee dat je gaan regeren, het 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: Hartelijk 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 dit zeggen over het inschakelen van de productiviteit van analisten. 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 in een bedrijf wordt gevestigd, en misschien het belangrijkste om te zeggen, is dat veel ervan automatisch gebeurt, dus Dez sprak over systemen, het 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 Alations-catalogus 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 het centraliseren van dingen in een datacatalogus levert op zichzelf niet 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-verzen 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 con, 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 con 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 plek 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 webgebaseerde query-tool en ik zal het je in een seconde laten zien. Een webgebaseerd queryhulpprogramma dat werkt met al die database-logo's die u op de vorige dia zag. Wat ik vooral 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 laat dat goed 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 laat dat goed zien.

En vervolgens voorbeelden. Voorvertoningen zijn, zoals u de naam van een object typt, we laten u alles zien wat de catalogus weet, of op zijn minst de meest relevante dingen die de catalogus over dat object weet. Dus monsters 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 praten, ga ik naar de demo, en ik ga gewoon wachten tot het verschijnt. Wat ik je hier ga laten zien is de querytool. 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 sprong een beetje over de catalogusinterface, rechtstreeks naar hoe het direct werd ingevoerd om de workflow te bedienen.

Ik laat hier gewoon een plek zien waar ik SQL kan typen, en onderaan zie je dat we soort informatie hebben over de objecten waarnaar werd verwezen. Dus ik ga gewoon beginnen met het typen van een zoekopdracht en ik stop ermee als ik bij een van deze interventies kom. Dus typ ik "selecteren" 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. Dus er zijn enkele openbaarmakingsregels. Als ik deze gegevens ga opvragen, ga ik gegevens uit deze tabel halen, moet ik 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 weet op het moment dat ik naar de gegevens kijk.

Dus ik heb dat naar me toe komen en dan ga ik ook naar collegegeld kijken. En hier zien we de previews in het spel komen. Op deze collegekolom zie ik - er is een collegekolom op de instellingslijst, en ik zie daar een profiel van. Alation gaat en haalt voorbeeldgegevens uit de tabellen, en in dit geval laat het me iets zien 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 enig idee 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 vraag ben, waar ik van tevoren veel profileervragen zou doen. Telkens wanneer ik een nieuw stuk gegevens nader, denk ik altijd na over wat onze gegevensdekking is. Maar als ik nieuw ben in data-analyse, als ik nieuw ben in deze dataset, zou ik kunnen veronderstellen dat als er een kolom is, deze de hele tijd is ingevuld. Of ik neem aan dat als het niet is ingevuld, het niet nul is, het nul is 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 opvalt over 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 gaat altijd, maar met name hier heb ik zelfs niets 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 enige interventie. Als ik naar een van deze kijk, krijgt het een waarschuwing die me laat zien dat dit alleen moet worden gebruikt voor geaggregeerde analyse. Het zal waarschijnlijk de verkeerde zaak zijn 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 noodzakelijk enig inzicht te hebben in wat de gegevens zijn. Ik heb eigenlijk nooit gekeken naar een ER-diagram van deze gegevensverzameling, 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 tijdens het schrijven van vragen. 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 opgenomen - en hier zie je nog wat meer van de catalogusinterface - ga ik naar een specifieke zoekopdracht voor zoekopdrachten die me een manier laat zien om zoekopdrachten in de hele organisatie te vinden. 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 expert op deze vraag en op deze gegevensobjecten. Dat is erg handig als mensen gegevens moeten leren kennen, en dan de juiste persoon kunnen vinden om te leren. En als ik echt nieuw ben in gegevens, 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 gegevensset. 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 een door Phil Mazanett over de gemiddelde SAT-scores. Klik hierop en ik krijg een soort cataloguspagina voor de zoekopdracht zelf. Het gaat over een artikel dat is geschreven dat verwijst naar deze vraag, 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 beetje van onze lichtgewicht rapportagemogelijkheden te zien, waar u tijdens het schrijven van een query een sjabloonvariabele zoals deze kunt invoeren en het creëert een eenvoudige manier om een ​​formulier te maken om een ​​query uit te voeren op basis van een enkele parameters.

Dus dat is wat ik heb 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. Heel erg bedankt.

Rebecca Jozwiak: Heel erg bedankt David. Ik ben er zeker van 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 eigen app store en ik denk dat dit echt een geweldige basis is om daarop verder 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 ook toen transformeren hun interne culturele en gedragskenmerken rond. 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 waar klanten over praten als 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 schrijven Helemaal geen 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:" Nou, het is echt gewoon omdat ik kan inloggen en ik kan al deze bestaande query's zien. ”Beginnen met een lege lei met SQL is een ongelooflijk moeilijk ding om te doen, maar het wijzigen van een bestaande query waar u het resultaat kunt zien dat wordt geplaatst en u kunt zeggen:“ Oh , Ik heb alleen deze extra kolom nodig, 'of' ik moet het filteren op een bepaald datumbereik ', dat is veel gemakkelijker 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. Ive probeerde 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. heeft een interne tool gehad die ze HiPal hebben genoemd en die alle vragen die op Hive zijn geschreven hebben vastgelegd, maar wat je erachter komt is dat als je de gebruikers niet op de juiste manier een duwtje geeft, je gewoon een zeer lange lijst krijgt van geselecteerde uitspraken. En als een gebruiker 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 langer 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 doorgemaakt, 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 andere mensenprogramma's hakte en de cursussen er 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, in feite diezelfde parallel zag, 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 omslagpunt in de tijd als mensen je platform krijgen geïnstalleerd en begonnen ze de soorten tools te ontdekken? Hoe snel zien mensen dit soort dingen gewoon veranderen in een echt onmiddellijk "a-ha" -moment 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 het een beetje aanraken. Ik denk dat wanneer 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 een soort pagina moet invullen door bladzijde. En dit geldt min of meer voor eerdere gegevensoplossingen waarbij 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 bevat. 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 wel een jaar nodig hebben om te implementeren en te implementeren en op te staan.

De laatste vraag die ik voor je heb gesteld voordat ik Robin Bloor overhandig, zijn connectoren. Een van de dingen die meteen naar me springt, is dat je die hele uitdaging duidelijk hebt opgelost. Dus er zijn 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 datasystemen die niet publiekelijk beschikbaar zijn, en vaak zonder interne informatie. 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 querylogboek beheren, er zijn verschillende configuraties en het is iets waar je echt aan moet 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 sinds we het 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 voor het 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 geen dingen zijn die 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 gingen 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: Jazeker. Sorry, ik heb mezelf gedempt. Wat is het proces als 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 tuurlijk. We gaan in, eerst een soort IT-proces om ervoor te zorgen dat onze servers worden 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. Help ze goed om een ​​eerste blik te werpen op hun querylogboek om te begrijpen wie wat gebruikt en hoeveel gebruikers ze op een systeem hebben. Zo goed helpen om uit te vinden waar - ze, vaak, als ze honderden of duizenden mensen hebben die zich mogelijk aanmelden bij databases, weten ze eigenlijk niet waar ze inloggen, dus we kunnen uit de querylogboeken achterhalen hoeveel unieke gebruikersaccounts u heeft zich hier in een maand of zo eigenlijk ingelogd en voert hier zoekopdrachten uit.

Daar kunnen we dus gebruik van maken, maar vaak alleen van de belangrijkste. We zetten ze op en dan is er 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. Zodra mensen het hulpprogramma voor zoekopdrachten 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 geen installaties omvat 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 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 wat enkele van de verschillen zijn tussen een webgebaseerde of servergebaseerde querytool versus een die u op uw bureaublad zou hebben, en enkele nuances van het gebruik daarvan. 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 binnenkomen 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 uw eigen queryhistorie bekijken, deze dingen publiceren zodat ze verschijnen als de eerste zoekopdrachten. 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 zoeken zijn, zodat u enkele nuances kent over hoe u het kunt gebruiken.

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 opgezet en die in het systeem zijn ontstaan, en waren gericht op de meest waardevolle en meest waardevolle stukken metadata die we op de tabelpagina's kunnen krijgen, zodat wanneer u zoekt, je vindt iets nuttigs.

Robin Bloor: Oke. De andere vraag - er zijn veel vragen van 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 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 zal op de korte termijn 10, 20, 30 mensen moeten inhuren die nieuwe inzichten uit deze gegevens moeten produceren, hoe gaan ze op snelheid?" Dus onboarding van analisten is iets dat we zeker aanpakken. Er zijn ook gewoon de senior analisten ontlast van het besteden van al hun tijd aan het beantwoorden van vragen van andere mensen over gegevens. Dat is ook een zeer frequente. 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 dat is een andere plaats waar mensen naar ons toe komen.

Robin Bloor: Oké, ik geef je door 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 de pijn zelf gezien bij vorige bedrijven, waar je gebruikers moet trainen. Bijvoorbeeld: “Dit is een logboektabel, de logboeken gaan al jaren terug. Als je een vraag over deze tafel gaat schrijven, moet je je echt beperken tot de datum. '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 nuttig, toch? Dus bij een bepaalde join kunt u 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 u ernaar wilt zoeken, een datumbereik hebben, u kunt op de tabelpagina opgeven dat u 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 ze willen . Ze zouden ze niet volledig verbieden om het te gebruiken - het is ook een vraag, het moet aan het einde van de dag vragen 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 zoekopdrachten in deze tabel gebruikmaakt van een bepaald filter of een bepaalde join-clausule, laat dat dan zien. Wel, bevorder dat 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, sinds zijn soort - 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 echt 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 niet noodzakelijkerwijs mensen zult blokkeren van het verzamelen van middelen, maar ze soort van 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: Oke. 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 het is vaker, als het een beoefenaar in zijn werk gaat inschakelen, het is waarschijnlijker dat het een gegevensarchitect zoals een DBA inschakelt.

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. Dat is wanneer u begint na te denken over prestaties en nauwkeurigheid, en ook begrijpt 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 te verklaren. 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 ik heb opgemerkt, zoals ik de explosie van de verschillende soorten databases, van documentdatabases, van grafiedatabases, 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. Dit 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, is dat aan het eind van de dag, dat is wat mensen 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 alles werd gezegd, werd zeer 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 zeker 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 uw brongegevens vaak, wanneer u een datawetenschapper bent en in een scripttaal werkt, relationeel zijn 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: Oke geweldig. Ik weet dat we een beetje voorbij de top van het uur lopen, 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: Zeker. Er zijn een paar manieren om dat te doen. Ik bedoel, extern gehost, zou ik me voorstellen, ik probeer precies na te denken over wat dat 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 als we die dingen dan niet hebben, hebben we iets dat een virtuele gegevensbron wordt genoemd, waarmee je in wezen documentatie kunt pushen, automatisch, door je eigen connector te schrijven, of door het in te vullen door het te doen zoals een CSV-upload de gegevens naast uw interne gegevens. 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 gewoon nog een vraag voor je uit. Een 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 - een van onze filosofieën, zoals ik al zei, we niet geloven 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 Alations 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 goed zijn, kunnen ze teruggaan en ze aanpassen en informeren, en hopelijk zelfs contact opnemen met de gebruiker 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. Je kan ook .

Rebecca Jozwiak: Oke geweldig. En ik weet het, deelnemers, sorry als ik vandaag niet op alle vragen ben gekomen, maar als dat niet zo is, zullen ze worden doorgestuurd naar David of zijn verkoopteam of iemand bij Alation, zodat ze zeker kunnen helpen je vragen te beantwoorden en te helpen begrijpen wat Alation is doet of wat ze het beste doen.

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 u vaarwel. Bedankt mensen. Tot ziens.

David Crawford: Dank je.