Par Techopedia Staff, 22 juin 2016
À retenir : l' animatrice Rebecca Jozwiak discute des avantages des catalogues de données avec Dez Blanchfield, Robin Bloor et David Crawford.
Vous devez vous inscrire à cet événement pour voir la vidéo. Inscrivez-vous pour voir la vidéo.
Rebecca Jozwiak: Mesdames et messieurs, bonjour et bienvenue à Hot Technologies de 2016. Aujourd'hui, nous avons, "Le pouvoir de la suggestion: comment un catalogue de données habilite les analystes." Je suis votre hôte Rebecca Jozwiak, remplaçant notre hôte habituel Eric Kavanagh aujourd'hui, alors qu'il parcourt le monde, alors merci de vous joindre à nous. Cette année est chaude, ce n'est pas seulement chaud au Texas où je suis, mais il fait chaud partout. Il y a une explosion de toutes sortes de nouvelles technologies qui sortent. Nous avons l'IoT, les données en streaming, l'adoption du cloud, Hadoop continue de mûrir et d'être adopté. Nous avons l'automatisation, l'apprentissage automatique et tout cela est bien sûr souligné par les données. Et les entreprises sont de plus en plus alimentées par la journée. Et bien sûr, le but est de conduire à la connaissance, à la découverte et, vous savez, à prendre de meilleures décisions. Mais pour tirer le meilleur parti des données, il faut que ce soit facile d'accès. Si vous le gardez enfermé, enfoui ou dans le cerveau de quelques personnes au sein de l'entreprise, cela ne fera pas beaucoup de bien à l'entreprise dans son ensemble.
Et je pensais au catalogage des données et je pensais bien sûr aux bibliothèques, où il y a longtemps que vous alliez si vous aviez besoin de trouver quelque chose, si vous deviez rechercher un sujet ou rechercher des informations, vous alliez à la bibliothèque, et bien sûr, vous êtes allé au catalogue de cartes, ou la dame de crabe qui y travaillait. Mais c'était aussi amusant de se promener, si vous vouliez juste regarder, et bien sûr vous pourriez simplement découvrir quelque chose de bien, vous pourriez découvrir des faits intéressants que vous ne saviez pas, mais si vous aviez vraiment besoin de trouver quelque chose, et vous saviez ce que vous cherchiez, vous aviez besoin du catalogue de cartes, et bien sûr l'équivalent d'entreprise est un catalogue de données, qui peut aider à mettre en lumière toutes les données pour que nos utilisateurs puissent enrichir, découvrir, partager, consommer et vraiment aider les gens accèdent aux données plus rapidement et plus facilement.
Donc, aujourd'hui, nous avons Dez Blanchfield, notre propre scientifique des données, et nous avons le docteur Robin Bloor, notre propre analyste en chef, nous avons David Crawford d'Alation, qui va parler de l'histoire de catalogage de données de son entreprise, mais d'abord nous allons commencer avec Dez. Dez, je vous passe le ballon et la parole est à vous.
Dez Blanchfield: Merci, merci de m'accueillir aujourd'hui. C'est une question qui m'intéresse énormément, parce que presque toutes les organisations que je rencontre dans mon travail quotidien, je trouve exactement le même problème dont nous avons parlé très brièvement dans les plaisanteries d'avant-spectacle, et c'est que la plupart des organisations qui sont en affaires depuis plus de quelques années ont une pléthore de données enfouies autour de l'organisation, différents formats, et en fait j'ai des clients qui ont des ensembles de données qui reviennent à Lotus Notes, des bases de données qui fonctionnent toujours dans certains cas comme leurs pseudo internets, et eux, tous se heurtent à ce défi de trouver réellement où se trouvent leurs données, et comment y accéder, qui leur donner accès, quand leur donner accès, et comment simplement catalogue, et comment l'obtenir à un endroit où tout le monde peut: A) être conscient de ce qu'il y a et de ce qu'il contient, et B), comment y accéder et l'utiliser. Et l'un des plus grands défis est bien sûr de le trouver, l'autre grand défi est de savoir ce qu'il y a dedans et comment y accéder.
Je sais peut-être que j'ai des dizaines de bases de données, mais je ne sais pas vraiment ce qu'il y a dedans ni comment savoir ce qu'il y a dedans, et donc invariablement comme nous le découvrons maintenant dans les données d'avant-spectacle, vous avez tendance pour me promener dans le bureau et poser des questions, et crier à travers les murs cubiques et essayer de comprendre, souvent mon expérience est, vous pouvez même trouver que vous vous promenez à la réception, à la réception, et demandez si quelqu'un sait qui tu vas aller parler. Très souvent, ce ne sont pas toujours les informaticiens parce qu'ils ne connaissent pas l'ensemble de données parce que quelqu'un vient de le créer, et cela pourrait être quelque chose de simple - assez souvent, nous trouverons un projet quelconque qui résiste dans l'environnement informatique et le gestionnaire de projet a utilisé une feuille de calcul de toutes choses, et il a obtenu une énorme quantité d'informations précieuses sur les actifs, le contexte et les noms, et à moins que vous ne connaissiez ce projet et que vous connaissiez cette personne, vous ne pouvez tout simplement pas trouver ces informations. Il n'est tout simplement pas disponible et vous devez vous procurer ce fichier d'origine.
Il y a une phrase qui a été plaisantée en ce qui concerne les données et je ne suis pas nécessairement d'accord avec elle, mais je pense que c'est un joli petit jetable et c'est qu'un certain nombre de personnes pensent que les données sont la nouvelle huile, et je suis nous allons certainement couvrir cela sous certains aspects, plus tard dans la journée. Mais ce que j'ai remarqué, faisant certainement partie de cette transformation, c'est que les organisations d'entreprises qui ont appris à valoriser leurs données ont acquis un avantage significatif sur leurs concurrents.
Il y a environ cinq ou six ans, il y avait un article intéressant d'IBM, et ils ont interrogé environ 4000 entreprises ici en Australie, et ils ont pris toutes les informations, toutes les données de performance, toutes les données financières et les ont rassemblées dans une marmite bouillante, puis envoyé à l'Australian School of Economics, et ils ont en fait commencé une tendance commune ici, à savoir que les entreprises qui tiraient parti de la technologie gagnaient invariablement un avantage concurrentiel par rapport à leurs pairs et concurrents en soi que leurs concurrents ne rattrapent presque jamais, et je pense c'est bien le cas maintenant avec les données que nous avons vu ce que les gens appellent une transformation numérique où les organisations qui ont clairement compris comment trouver les données dont elles disposent, les rendre disponibles et les rendre disponibles dans un consommable très facile mode à l'organisation, sans nécessairement toujours savoir pourquoi l'organisation pourrait en avoir besoin, et gagner un avantage significatif sur ses concurrents.
J'ai quelques exemples sur cette diapositive, que vous pouvez voir. Ma seule ligne est, c'est que la perturbation à grande échelle dans presque tous les secteurs de l'industrie, à mon avis, est motivée par les données, et si les tendances actuelles se poursuivent, je pense que nous venons tout juste de a commencé parce que lorsque les marques de longue date se réveilleront enfin sur ce que cela signifie et entreront dans le jeu, elles entreront dans le jeu en gros. Lorsque les principaux détaillants qui ont des montagnes de données commencent à appliquer une analyse historique des données, s'ils savent même qu'elles existent, certains des joueurs en ligne vont recevoir un petit coup de semonce.
Mais avec beaucoup de la plupart de ces marques, je veux dire que nous avons Uber qui est la plus grande compagnie de taxi au monde. Ils ne possèdent pas de taxis, alors qu'est-ce qui les rend magiques, quelles sont leurs données? Airbnb, le plus grand fournisseur d'hébergement, nous avons WeChat, la plus grande compagnie de téléphone au monde, mais ils n'ont pas d'infrastructure réelle, ni de combinés, ni de lignes téléphoniques. Alibaba, le plus grand détaillant de la planète, mais ils ne possèdent aucun des stocks. Facebook, la plus grande entreprise médiatique du monde. Je pense qu'au dernier décompte, ils comptaient maintenant 1, 4 milliard d'utilisateurs de données actifs, ce qui est ahurissant. Ce n'est pas du tout proche - je pense que quelqu'un a prétendu qu'un quart de la planète est en fait là-bas chaque jour, et pourtant voici un fournisseur de contenu qui ne crée pas réellement le contenu, toutes les données qu'ils servent ne sont pas créées par eux, elles sont créées par leurs abonnés, et nous connaissons tous ce modèle.
SocietyOne, dont vous avez peut-être entendu parler ou non, c'est une marque locale, je pense que dans quelques pays c'est une banque qui fait des prêts peer-to-peer, donc en d'autres termes, elle n'a pas d'argent. Il ne fait que gérer les transactions et les données se trouvent en dessous. Netflix, nous sommes tous très, très familiers avec cela. Il y a un one-liner intéressant ici. Lorsque Netflix pouvait légalement être utilisé en Australie, quand il a été officiellement annoncé, vous n'aviez pas besoin d'utiliser un VPN pour y accéder, de nombreuses personnes dans le monde ont tendance à le faire - si vous ne pouvez pas y accéder dans votre région - lorsque Netfix a été lancé en Australie, il a augmenté la bande passante internationale de nos liaisons Internet de 40%, ce qui a presque doublé l'utilisation d'Internet en Australie du jour au lendemain, par une seule application, une application hébergée dans le cloud qui ne fait que jouer avec les données. C'est juste une statistique ahurissante.
Et bien sûr, nous connaissons tous Apple et Google, mais ce sont les plus grandes entreprises de logiciels de la planète, mais elles n'écrivent pas réellement les applications. Quelle est la chose cohérente avec toutes ces organisations? Eh bien, ce sont des données, et ils n'y sont pas arrivés parce qu'ils ne savaient pas où se trouvaient leurs données, et ils ne savaient pas comment les cataloguer.
Ce que nous constatons maintenant, c'est qu'il y a cette toute nouvelle classe d'actifs appelée données, et les entreprises s'y réveillent. Mais ils n'ont pas toujours les outils, le savoir-faire et les raisons de cartographier toutes ces données, de cataloguer toutes ces données et de les rendre disponibles, mais nous avons constaté que les entreprises n'ayant pratiquement aucun actif physique ont acquis une valeur de marché élevée dans un temps record via cette nouvelle classe d'actifs de données. Comme je l'ai dit, certains des anciens joueurs s'éveillent maintenant à cela et le font certainement ressortir.
Je suis un grand fan de prendre des gens pour un petit voyage, donc dans les dix-huit centaines, fin dix-huit cents, et vous serez plus que familier avec cela sur le marché américain, il s'est avéré que pour effectuer un recensement chaque année environ, je pense qu'ils les ont exécutés tous les dix ans à ce moment-là, mais si vous allez effectuer un recensement chaque année, cela pourrait prendre jusqu'à huit ou neuf ans pour faire l'analyse des données. Il s'est avéré que cet ensemble de données a ensuite été laissé dans des boîtes dans des endroits sur papier, et presque personne ne pouvait le trouver. Ils ne cessaient de pomper ces rapports, mais les données réelles étaient très difficiles à obtenir, nous avons une situation similaire avec un autre moment significatif mondial, autour des années 1940, avec la Seconde Guerre mondiale, et cette chose est le Bletchley Park Bombe orthographié BOMBE, et c'était un outil analytique de calcul des nombres massif qui passerait par de petits ensembles de données et y trouverait des signaux, et serait utilisé pour aider à déchiffrer les codes à travers l'Enigma.
Encore une fois, cette chose était essentiellement un appareil conçu, pas beaucoup pour cataloguer, mais pour étiqueter et mapper des données, et permettre de prendre des modèles et de les trouver dans les ensembles de données, dans ce cas, de casser les codes, de trouver des clés et des phrases les régulièrement dans les ensembles de données, et nous avons donc traversé ce parcours de recherche de choses dans les données, et menant vers le catalogage des données.
Et puis ces choses sont arrivées, ces énormes racks de machines à bas prix, juste des machines standard. Et nous avons fait des choses très intéressantes, et l'une des choses que nous avons faites avec eux est que nous avons construit des grappes à très faible coût qui pourraient commencer à indexer la planète, et très célèbre ces grandes marques qui sont passées et disparues, mais probablement la maison la plus courante de Google marque dont nous avons tous entendu parler - c'est devenu un verbe réel, et vous savez que vous réussissez lorsque votre marque devient un verbe. Mais ce que Google nous a appris, sans s'en rendre compte, peut-être dans le monde des affaires, c'est qu'ils ont pu indexer la planète entière à un certain niveau, cataloguer les données qui étaient dans le monde et les rendre disponibles très facilement, formulaire pratique dans une toute petite formule d'une ligne, une page Web avec presque rien dessus, et vous tapez votre requête, elle va et la trouve parce qu'ils avaient déjà exploré la planète, indexée et rendue facilement disponible.
Et ce que nous avons remarqué était: «Eh bien, attendez, nous ne faisons pas cela dans les organisations - pourquoi? Pourquoi est-ce que nous avons une organisation qui peut cartographier la planète entière et l'indexer, l'explorer et l'indexer, et la rendre disponible, nous pouvons la rechercher, puis cliquer sur la chose pour aller la trouver, comment se fait-il n'avez pas fait ça en interne? »Il y a donc beaucoup de ces petits racks de machines à travers le monde qui le font pour les intranets et trouvent des choses, mais ils n'arrivent toujours vraiment à comprendre l'idée d'aller au-delà du web traditionnel page ou un serveur de fichiers.
Au lieu d'entrer maintenant dans cette nouvelle génération de catalogue de données de plusieurs façons, la découverte de l'accès aux données via des notes post-it et des conversations sur un refroidisseur d'eau n'est plus vraiment une méthode appropriée pour la découverte de données et le catalogage, et en fait, je ne pense jamais était vraiment. Nous ne pouvons plus diriger tout ce défi pour les gens qui ne font que passer des notes, publier des notes et en discuter. Nous sommes bel et bien au-delà du domaine où cette approche de nouvelle génération en matière de catalogage de données a disparu. Nous devons contourner cela. Si c'était un problème facile, nous l'aurions déjà résolu de nombreuses façons plus tôt, mais je pense que ce n'est pas un problème facile, l'indexation et l'appel des données ne sont qu'une partie de celui-ci, sachant ce qu'il y a dans les données et construire des métadonnées autour de ce que nous découvrons, puis les rendre disponibles sous une forme facile et consommable, en particulier pour le libre-service et l'analyse. C'est toujours un problème à résoudre, mais de nombreuses parties du puzzle en cinq ans sont bel et bien résolues et disponibles.
Comme nous le savons, le catalogage des données par les humains est une recette pour l'échec car l'erreur humaine est l'un des plus grands cauchemars que nous traitons dans le traitement des données, et je parle régulièrement de ce sujet où, à mon avis, les humains remplissant des formulaires papier sont probablement le plus grand cauchemar nous traitons dans les mégadonnées et les analyses, d'avoir constamment à réparer les choses qu'ils font, même des choses simples comme les dates et les champs, les gens qui les mettent dans le mauvais format.
Mais comme je l'ai dit, nous avons vu des moteurs de recherche sur Internet indexer le monde chaque jour, alors maintenant nous en arrivons à l'idée que cela peut être fait sur des ensembles de données d'entreprise dans le processus de découverte, et des outils et des systèmes sont maintenant facilement disponible que vous êtes sur le point d'apprendre aujourd'hui. Donc, à mon avis, l'astuce consiste à sélectionner les bons outils, les meilleurs outils pour le travail. Et de façon plus appropriée, en plus de trouver la bonne partie pour vous aider à démarrer dans cette voie. Et je crois que nous allons en entendre parler aujourd'hui, mais avant de le faire, je vais passer à mon collège, Robin Bloor et entendre son point de vue sur le sujet. Robin, je peux te passer la parole?
Robin Bloor: Oui, certainement vous le pouvez. Voyons voir si ça marche, oh oui ça marche. D'accord, je viens d'une direction différente de celle de Dez, mais je vais finir au même endroit. Il s'agit de se connecter aux données, donc je pensais juste parcourir la réalité de la connexion aux données, point par point vraiment.
Il est un fait que les données sont plus fragmentées qu'elles ne l'ont jamais été. Le volume de données augmente de façon phénoménale, mais en réalité, les différentes sources de données augmentent également à un rythme incroyable, et donc les données deviennent de plus en plus fragmentées tout le temps. Mais à cause des applications analytiques en particulier - mais ce ne sont pas les seules applications - nous avons une très bonne raison de nous connecter à toutes ces données, donc nous sommes coincés dans un endroit difficile, nous sommes coincés dans un monde de données fragmentées, et il y a des opportunités dans les données comme l'appelait Dez, le nouveau pétrole.
En ce qui concerne les données, eh bien, elles vivaient sur un disque tournant, que ce soit dans des systèmes de fichiers ou des bases de données. Maintenant, il vit dans un environnement beaucoup plus varié, il vit dans des systèmes de fichiers mais il vit également dans des instances Hadoop de nos jours, ou même des instances Spark. Il vit dans plusieurs espèces de bases de données. Il n'y a pas si longtemps, nous avons en quelque sorte standardisé une base de données relationnelle, eh bien vous savez qui a disparu par la fenêtre au cours des cinq dernières années, car il y a un besoin de bases de données de documents, et il y a un besoin de bases de données graphiques, donc modifié. Il vivait donc sur disque tournant, mais il vit maintenant sur SSD. La dernière quantité de SSD - certainement la dernière unité SSD sort de Samsung - vingt gigaoctets, ce qui est énorme. Maintenant, il vit en mémoire, dans le sens où la copie principale des données peut être en mémoire, plutôt que sur disque, nous n'avions pas l'habitude de construire des systèmes comme ça; nous le faisons maintenant. Et il vit dans le cloud. Ce qui signifie qu'il peut vivre dans n'importe laquelle de ces choses, dans le cloud, vous ne saurez pas nécessairement où il se trouve dans un cloud, vous n'aurez que son adresse.
Juste pour ramener le clou, Hadoop a jusqu'à présent échoué en tant que magasin de données extensible. Nous avions espéré qu'il deviendrait un magasin de données évolutif extensible, et qu'il deviendrait simplement un système de fichiers pour tout, et il le ferait - des arcs-en-ciel apparaîtraient dans le ciel, essentiellement, et des licornes danseraient, et rien de tout cela ne s'est produit. Ce qui signifie que nous nous retrouvons avec un problème de transport de données, et qu'il n'y a pas une nécessité de transport de données, parfois, mais c'est aussi une difficulté. Les données ont vraiment de la gravité de nos jours, une fois que vous avez pénétré dans les plusieurs téraoctets de données, les récupérer et les jeter, ce qui fait apparaître des latences sur votre réseau ou à divers endroits. Si vous souhaitez transporter des données, le timing est un facteur. De nos jours, il y a presque toujours des limites au temps dont vous disposez pour obtenir une chose, des données d'un endroit à un autre. Il y avait autrefois ce que nous avions l'habitude de considérer comme des fenêtres batch, lorsque la machine était un peu inactive, et peu importe la quantité de données que vous aviez, vous pouviez simplement la jeter et tout fonctionnerait. Eh bien, c'est parti, nous vivons dans un monde beaucoup plus en temps réel. Par conséquent, le timing est un facteur. Dès que vous souhaitez déplacer des données, donc si les données ont de la gravité, vous ne pouvez probablement pas les déplacer.
La gestion des données est un facteur dans le sens où vous devez réellement gérer toutes ces données, vous ne les obtenez pas gratuitement, et une réplication peut être nécessaire afin que les données fassent le travail qu'elles doivent faire, car ce n'est peut-être pas là où vous l'avez mis. Il peut ne pas disposer de ressources suffisantes pour effectuer le traitement normal des données. Ainsi, les données sont répliquées et les données sont répliquées plus que vous ne l'imaginez. Je pense que quelqu'un m'a dit il y a longtemps que la donnée moyenne était répliquée au moins deux fois et demie. Les ESB ou Kafka présentent une option pour le flux de données, mais de nos jours cela demande une architecture. De nos jours, vous devez vraiment réfléchir d'une manière ou d'une autre à ce que signifie réellement jeter les données. Par conséquent, pour accéder aux données où elles se trouvent, il est généralement préférable, tant que, bien sûr, vous pouvez obtenir les performances dont vous avez besoin lorsque vous allez réellement chercher les données et cela dépend du contexte. C'est donc une situation difficile de toute façon. En termes de requêtes de données, nous pouvions penser en termes de SQL, nous avons vraiment trouvé maintenant, vous savez, différentes formes de requêtes, SQL oui, mais adjacentes, également des requêtes graphiques, Spark n'est qu'un exemple de faire des graphiques, parce que nous devons aussi faire de la recherche de texte, plus que jamais, aussi des recherches de type regex, ce qui est des recherches de motifs vraiment compliquées, et une véritable correspondance de motifs, toutes ces choses bouillonnent. Et tous sont utiles car ils vous donnent ce que vous cherchez, ou ils peuvent vous obtenir ce que vous cherchez.
Les requêtes couvrent désormais plusieurs jours, ce qui n'a pas toujours été le cas, et les performances sont souvent épouvantables si vous le faites. Cela dépend donc des circonstances, mais les gens s'attendent à pouvoir interroger les données de plusieurs sources de données, de sorte que la fédération de données d'une sorte ou d'une autre devient de plus en plus courante. La virtualisation des données, qui est une manière différente de le faire, selon les performances, est également très courante. Les requêtes de données font en fait partie d'un processus, pas de tout le processus. Il convient de souligner que si vous examinez réellement les performances analytiques, les analyses réelles peuvent prendre beaucoup plus de temps que la collecte de données, car cela dépend des circonstances, mais les requêtes de données sont une nécessité absolue si vous souhaitez effectuer une type d'analyse sur plusieurs sources de données, et juste, vous devez vraiment avoir des capacités qui s'étendent.
Donc, sur les catalogues. Les catalogues existent pour une raison, au moins nous disons que, vous savez, c'est, nous avons des répertoires, et nous avons des schémas dans des bases de données, et nous avons chaque catalogue et nous avons partout où vous allez, vous trouverez un endroit et ensuite vous aurez réellement trouver qu'il existe une sorte de catalogue, et le catalogue mondial unifié est une très bonne idée. Mais très peu d'entreprises ont une telle chose. Je me souviens, en l'an 2000 - la panique de l'an 2000 - je me souviens que les communistes ne pouvaient même pas déterminer le nombre d'exécutables qu'ils avaient, sans se soucier du nombre de magasins de données différents qu'ils avaient, et c'est probablement le cas maintenant, vous savez, que la plupart des entreprises ne savent pas activement, au sens mondial, quelles données elles ont. Mais il devient évidemment de plus en plus nécessaire d'avoir réellement un catalogue mondial, ou du moins d'avoir une image globale de ce qui se passe en raison de la croissance des sources de données et de la croissance continue des applications, et cela est particulièrement nécessaire pour l'analyse, parce que vous aussi dans un sens, et il y a d'autres problèmes ici comme la lignée et les problèmes avec les données, et c'est nécessaire pour la sécurité, de nombreux aspects de la gouvernance des données, si vous ne savez vraiment pas quelles données vous avez, l'idée que vous allez gouverner est tout simplement absurde. Donc, en cela, toutes les données sont cataloguées d'une certaine manière est juste un fait. La question est de savoir si le catalogue est cohérent et en fait ce que vous pouvez en faire. Je vais donc revenir à Rebecca.
Rebecca Jozwiak: D'accord, merci Robin. Ensuite, nous avons David Crawford d'Alation, David Je vais aller de l'avant et vous passer le ballon, et vous pouvez le retirer.
David Crawford: Merci beaucoup. J'apprécie vraiment que vous m'ayez fait participer à cette émission. Je pense que je vais commencer, donc je pense que mon rôle ici est de prendre une partie de cette théorie et de voir comment elle est réellement appliquée, et les résultats que nous sommes en mesure de générer chez de vrais clients et ainsi vous pouvez voir quelques-uns sur la diapositive, je veux parler des résultats que nous pourrons voir dans l'analyse, éventuellement des améliorations. Donc, pour motiver la discussion, nous allons parler de la façon dont ils y sont arrivés. J'ai donc la chance de travailler en étroite collaboration avec beaucoup de gens vraiment intelligents, ces clients, et je veux juste en mentionner quelques-uns qui ont pu réellement mesurer, et parler de l'impact d'un catalogue de données sur leur analyste. workflow. Et juste pour rester brièvement à l'avant, je pense que l'une des choses que nous voyons changer, avec les catalogues de données vers les solutions médiées précédentes et l'une des façons dont les relations pensent vraiment aux solutions que nous mettons ensemble, est de partir des analystes et travailler à l'envers. Pour dire, faisons ceci pour permettre la productivité des analystes. Par opposition à la simple conformité, ou plutôt qu'à un simple inventaire, nous créons un outil qui rend les analystes plus productifs.
Donc, quand je parle à un scientifique des données de la société de services financiers Square, il y a un gars, Nick, qui nous expliquait comment le sien, il prenait plusieurs heures pour trouver le bon ensemble de données pour commencer un rapport, maintenant il peut le faire en quelques secondes en utilisant la recherche de part de marché, nous avons parlé à leur directeur technique qui a tiré ses analystes qui utilisaient Square, excusez-moi, utilisait Alation, pour savoir quels étaient leurs avantages, quels avantages ils avaient vus, et ils ont signalé un 50 pour cent d'augmentation de la productivité, et que l'un des meilleurs détaillants du monde, eBay, ils ont plus d'un millier de personnes qui effectuent régulièrement des analyses SQL, et je travaille assez étroitement avec Deb Says là-bas, qui est le projet responsable de leur équipe d'outils de données, et elle a constaté que lorsque les demandeurs adoptent Alation, adoptent un catalogue, ils voient doubler la vitesse d'écriture de nouvelles requêtes sur la base de données.
Ce sont donc de vrais résultats, ce sont des gens qui appliquent réellement le catalogue dans leur organisation, et je veux vous expliquer ce qu'il faut pour se mettre en place. La façon dont un catalogue est établi dans une entreprise, et peut-être la chose la plus importante à dire, c'est que cela se produit en grande partie automatiquement, alors Dez a parlé de systèmes, en apprenant sur les systèmes, et c'est exactement ce que fait un catalogue de données moderne. Ils installent donc Alation dans leur centre de données, puis ils le connectent à diverses sources de métadonnées dans leur environnement de données. Je vais me concentrer un peu sur les bases de données et les outils de BI - à partir de ces deux, nous allons extraire des métadonnées techniques, sur ce qui existe essentiellement. Bon, alors quelles tables? Quels rapports? Quelles sont les définitions de rapport? Ils extraient donc ces métadonnées techniques, et une page de catalogue est automatiquement créée pour chaque objet à l'intérieur de ces systèmes, puis, ils extraient et superposent également ces métadonnées techniques, ils superposent les données d'utilisation. Cela se fait principalement en lisant les journaux de requêtes dans la base de données, et c'est une source d'informations vraiment intéressante. Ainsi, chaque fois qu'un analyste écrit une requête, chaque fois qu'un outil de génération de rapports, qu'il soit développé à la maison ou prêt à l'emploi, qu'un outil de génération de rapports exécute une requête afin de mettre à jour le tableau de bord, lorsqu'une application exécute une requête pour insérer des données sur lesquelles opérer un ensemble de données - toutes ces choses sont capturées dans les journaux de requête de la base de données. Que vous ayez ou non un catalogue, ils sont capturés dans le journal des requêtes avec la base de données. Ce qu'un catalogue de données peut faire, et en particulier ce que le catalogue d'Alation peut faire, c'est lire ces journaux, poser les requêtes à l'intérieur d'eux et créer un graphique d'utilisation vraiment intéressant basé sur ces journaux, et nous mettons cela en jeu pour informer les futurs utilisateurs des données sur la façon dont les anciens utilisateurs des données les ont utilisées.
Donc, nous rassemblons toutes ces connaissances dans un catalogue, et juste pour rendre cela réel, ce sont les intégrations qui sont déjà déployées chez les clients, donc, nous avons vu Oracle, Teradata, Redshift, Vertica et un tas d'autres bases de données relationnelles. Dans le monde Hadoop, il existe une gamme de SQL sur Hadoop, sorte de méta-magasins relationnels au-dessus du système de fichiers Hadoop, Impala, Tez, Presto et Hive, nous avons également vu le succès avec des fournisseurs privés cloud Hadoop comme Altiscale, et nous ont également pu se connecter aux serveurs Tableau, aux serveurs MicroStrategy et y indexer les tableaux de bord, ainsi qu'aux intégrations avec des outils de cartographie de la science des données comme Plotly.
Donc, nous nous connectons à tous ces systèmes, nous avons connecté ces systèmes aux clients, nous avons extrait les métadonnées techniques, nous avons extrait les données d'utilisation et nous avons en quelque sorte automatiquement amorcé le catalogue de données, mais de cette façon, nous centraliser les connaissances, mais simplement centraliser les choses dans un catalogue de données, ne fournit pas en soi ces formidables gains de productivité dont nous avons parlé avec eBay, Square et la part de marché. Pour ce faire, nous devons en fait changer la façon dont nous pensons fournir des connaissances aux analystes. L'une des questions qu'ils se posent pour se préparer à cela était: «Comment le catalogue affecte-t-il réellement le flux de travail d'un analyste?»
C'est à cela que nous passons toute la journée à réfléchir, et pour parler de ce changement de pensée, d'un push vers un modèle pull, je voulais faire une rapide analogie avec ce qu'était le monde avant et après avoir lu sur un Kindle. Donc, c'est juste une expérience que certains d'entre vous pourraient avoir, lorsque vous lisez un livre physique, vous tombez sur un mot, vous n'êtes pas sûr de bien connaître la définition de ce mot, vous pouvez peut-être le deviner à partir du contexte, peu probable que vous vont se lever du canapé, marcher jusqu'à votre étagère, trouver votre dictionnaire, le dépoussiérer et retourner au bon endroit dans la liste alphabétique des mots pour vous assurer que, oui, vous aviez cette définition juste, et vous savez les nuances de celui-ci. Donc ça n'arrive pas vraiment. Donc, vous achetez une application Kindle et vous commencez à lire des livres là-bas, et vous voyez un mot dont vous n'êtes pas totalement sûr et vous touchez le mot. Tout d'un coup, dans ce même écran, se trouve la définition du mot dans le dictionnaire, avec toutes ses nuances, différents exemples d'utilisation, et vous glissez un peu et vous obtenez un article Wikipedia sur ce sujet, vous glissez à nouveau, vous obtenez un outil de traduction qui peut le traduire dans d'autres langues ou à partir d'autres langues, et tout à coup, votre connaissance de la langue est beaucoup plus riche, et cela arrive juste un nombre incroyable de fois, par rapport au moment où vous deviez aller et tirez cette ressource pour vous.
Et donc ce que je vais faire valoir, c'est que le flux de travail pour un analyste et la façon dont un analyste traitera la documentation des données, est en fait très similaire à la façon dont un lecteur interagira avec le dictionnaire, qu'il soit physique ou bien que le Kindle, et donc ce que nous, la façon dont nous avons vraiment vu cette augmentation de la productivité, n'est pas de renverser le catalogue, mais de le connecter au flux de travail de l'analyste, et donc, ils m'ont demandé de faire une démo ici, et je veux pour en faire l'objet de cette présentation. Mais je veux juste mettre en place le contexte de la démo. Lorsque nous pensons à transmettre la connaissance des données aux utilisateurs quand ils en ont besoin, nous pensons que le bon endroit pour le faire, l'endroit où ils passent leur temps et où ils font l'analyse, est un outil de requête SQL. Un endroit où vous écrivez et exécutez des requêtes SQL. Et donc nous en avons construit un, et nous l'avons construit, et ce qui est vraiment différent à ce sujet des autres outils de requête est son intégration profonde avec le catalogue de données.
Notre outil de requête s'appelle donc Alation Compose. C'est un outil de requête basé sur le Web et je vais vous le montrer dans une seconde. Un outil de requête basé sur le Web qui fonctionne sur tous les logos de base de données que vous avez vus sur la diapositive précédente. Ce que je vais essayer de faire une démonstration en particulier, c'est la façon dont les informations du catalogue parviennent aux utilisateurs. Et il le fait à travers ce genre de trois façons différentes. Il le fait par le biais d'interventions, et c'est là que quelqu'un qui est un gouverneur de données, ou un gestionnaire de données, ou une sorte d'administrateur d'une certaine manière, ou un gestionnaire, peut dire: «Je veux en quelque sorte interrompre avec une note ou un avertissement dans le flux de travail et assurez-vous qu'il est livré aux utilisateurs au bon moment. "C'est donc une intervention et nous allons le montrer.
Les suggestions intelligentes sont un moyen par lequel l'outil utilise toute sa connaissance agrégée du catalogue pour suggérer des objets et des parties d'une requête pendant que vous l'écrivez. La chose la plus importante à savoir est qu'il profite vraiment du journal des requêtes pour le faire, pour suggérer des choses en fonction de l'utilisation et également pour trouver même des parties de requêtes qui ont été écrites auparavant. Et nous allons le montrer.
Et puis des aperçus. Les aperçus sont, lorsque vous saisissez le nom d'un objet, nous vous montrons tout ce que le catalogue sait, ou du moins les choses les plus pertinentes que le catalogue sait sur cet objet. Ainsi, des échantillons des données, qui les avaient utilisées auparavant, le nom logique et la description de cet objet, vous parviennent tous pendant que vous l'écrivez sans avoir à aller le demander.
Alors sans plus parler, je vais passer à la démo, et je vais juste attendre qu'elle apparaisse. Ce que je vais vous montrer ici est l'outil de requête. Il s'agit d'une interface d'écriture SQL dédiée. C'est une interface distincte du catalogue, dans un certain sens. Dez et Robin ont parlé du catalogue, et je saute un peu sur l'interface du catalogue pour voir comment il est directement introduit pour gérer le flux de travail.
Je montre juste ici un endroit où je peux taper SQL, et en bas, vous verrez que nous avons en quelque sorte des informations apparaissant sur les objets que nous référençons. Je vais donc commencer à taper une requête et je m'arrêterai lorsque j'arriverai à l'une de ces interventions. Je vais donc taper «sélectionner» et je veux l'année. Je veux le nom. Et je vais chercher des données sur les salaires. Il s'agit donc d'un ensemble de données sur l'éducation. Il contient des informations sur les établissements d'enseignement supérieur, et je regarde le salaire moyen des professeurs qui figure dans l'un de ces tableaux.
J'ai donc tapé le mot «salaire». Ce n'est pas exactement le nom de la colonne de cette façon. Nous utilisons à la fois les métadonnées logiques et les métadonnées physiques pour faire des suggestions. Et ce que je veux souligner ici, c'est cette boîte jaune qui apparaît ici. Il indique qu'il y a un avertissement sur cette colonne. Je ne suis pas allé chercher ça, je n'ai pas pris de cours sur la façon d'utiliser correctement ces données. Cela m'est venu à l'esprit, et il se trouve que c'est un avertissement concernant un accord de confidentialité qui concerne ces données. Il y a donc des règles de divulgation. Si je vais interroger ces données, je vais retirer des données de ce tableau, je dois faire attention à la façon dont je les divulgue. Vous avez donc ici une politique de gouvernance. Il y a des défis de conformité qui rendent tellement plus facile de se conformer à cette politique quand je suis au courant au moment où je regarde les données.
J'ai donc cette idée à me proposer, puis je vais également examiner les frais de scolarité. Et ici, nous voyons les aperçus entrer en jeu. Sur cette colonne sur les frais de scolarité, je vois - il y a une colonne sur les frais de scolarité sur la table de l'institution, et j'en vois un profil. Alation va et extrait des données des tables, et dans ce cas, cela me montre quelque chose de très intéressant. Cela me montre la distribution des valeurs, et cela me montre que la valeur zéro est apparue 45 fois dans l'échantillon, et plus que toute autre valeur. J'ai donc le sentiment que nous pourrions manquer des données.
Si je suis un analyste avancé, cela pourrait déjà faire partie de mon flux de travail. Surtout si je suis particulièrement méticuleux, où je ferais un tas de requêtes de profilage à l'avance. Chaque fois que j'approche une nouvelle donnée, je pense toujours à notre couverture de données. Mais si je suis nouveau dans l'analyse des données, si je suis nouveau dans cet ensemble de données, je pourrais supposer que s'il y a une colonne, elle est remplie tout le temps. Ou je pourrais supposer que si ce n'est pas rempli, ce n'est pas zéro, c'est nul ou quelque chose comme ça. Mais dans ce cas, nous avons beaucoup de zéros, et si je faisais une moyenne, ils auraient probablement tort, si je supposais simplement que ces zéros étaient en fait zéro au lieu de données manquantes.
Mais Alation, en introduisant cet aperçu dans votre flux de travail, vous demande en quelque sorte de regarder ces informations et donne même à des analystes novices la possibilité de voir qu'il y a quelque chose à remarquer ici à propos de ces données. Nous avons donc cet aperçu.
La prochaine chose que je vais faire, c'est que je vais essayer de trouver de quels tableaux obtenir ces informations. Nous voyons donc ici les suggestions intelligentes. Cela a fonctionné tout le temps, mais en particulier ici, je n'ai même rien tapé mais cela va me suggérer les tables que je pourrais vouloir utiliser pour cette requête. Et la chose la plus importante à savoir à ce sujet est qu'elle tire parti des statistiques d'utilisation. Donc, dans un environnement comme, par exemple, eBay, où vous avez des centaines de milliers de tables dans une seule base de données, avoir un outil qui peut en quelque sorte frapper le blé de l'ivraie, et utiliser ces statistiques d'utilisation, est vraiment important pour faire ces suggestions valent quelque chose.
Il va donc suggérer ce tableau. Lorsque je regarde l'aperçu, nous mettons en évidence trois des colonnes que j'ai déjà mentionnées dans ma requête. Je sais donc qu'il y en a trois, mais il n'a pas de nom. J'ai besoin d'obtenir le nom, donc je vais faire une jointure. Lorsque je fais une jointure, j'ai à nouveau ces aperçus pour m'aider à trouver où se trouve la table avec le nom. Je vois donc que celui-ci a un nom bien formaté et bien capitalisé. Il semble y avoir une ligne avec un nom pour chaque institution, donc je vais saisir cela, et maintenant j'ai besoin d'une condition de jointure.
Et donc, ici, ce que fait Alation, c'est de nouveau regarder les journaux de requêtes, de voir les fois précédentes où ces deux tables ont été jointes, et de suggérer différentes façons de les rejoindre. Encore une fois, il y a une intervention. Si je regarde l'un d'entre eux, il y a un avertissement qui me montre que cela ne doit être utilisé que pour l'analyse agrégée. Cela produira probablement la mauvaise chose si vous essayez de faire quelque chose par l'institution. Alors que celui-ci, avec l'ID OPE est approuvé comme le bon moyen de joindre ces deux tables si vous voulez des données de niveau universitaire. Je fais donc cela, et c'est une courte requête, mais j'ai écrit ma requête sans vraiment avoir un aperçu de ce que sont les données. Je n'ai jamais réellement regardé un diagramme ER de cet ensemble de données, mais j'en sais déjà beaucoup sur ces données car les informations pertinentes me parviennent.
Ce sont donc les trois manières dont un catalogue peut, grâce à un outil de requête intégré, avoir un impact direct sur le flux de travail lorsque vous écrivez des requêtes. Mais l'un des autres avantages d'avoir un outil de requête intégré à un catalogue est que, lorsque je termine ma requête et que je l'enregistre, je peux mettre un titre comme «Frais de scolarité et salaire de la faculté», puis j'ai un bouton ici qui me permet de simplement le publier dans le catalogue. Il devient très facile pour moi de réinjecter cela. Même si je ne le publie pas, il est capturé dans le cadre du journal des requêtes, mais lorsque je le publie, il devient en fait une partie de la façon dont l'endroit centralisé où toutes les connaissances sur les données vivent.
Donc, si je clique sur Rechercher toutes les requêtes dans Alation, je vais être redirigé - et ici vous verrez un peu plus de l'interface du catalogue - je suis redirigé vers une recherche de requête dédiée qui me montre un moyen de trouver des requêtes à travers toute l'organisation. Et vous voyez que ma requête nouvellement publiée est en haut. Et certains pourraient remarquer ici, au fur et à mesure que nous capturons les requêtes, nous capturons également les auteurs, et nous établissons en quelque sorte cette relation entre moi en tant qu'auteur et ces objets de données dont je sais maintenant quelque chose. Et je suis en train de devenir un expert sur cette requête et sur ces objets de données. C'est vraiment utile lorsque les gens ont besoin de se renseigner sur les données, ils peuvent alors trouver la bonne personne pour en savoir plus. Et si je suis en fait nouveau dans les données, que je sois un analyste avancé - en tant qu'analyste avancé, je pourrais regarder cela et voir un tas d'exemples qui me permettraient de démarrer sur un nouvel ensemble de données. En tant que personne qui pourrait ne pas se sentir super avisée avec SQL, je peux trouver des requêtes prédéfinies qui sont des rapports dont je peux tirer parti.
En voici un par Phil Mazanett sur les scores médians SAT. Cliquez dessus, et j'obtiens une sorte de page de catalogue pour la requête elle-même. Il parle d'un article écrit qui fait référence à cette requête, il y a donc une documentation à lire si je veux apprendre à l'utiliser. Et je peux l'ouvrir dans l'outil de requête en cliquant sur le bouton Composer, et je peux simplement l'exécuter moi-même ici sans même le modifier. Et en fait, vous pouvez voir un peu de nos capacités de création de rapports légères, où, lorsque vous écrivez une requête, vous pouvez déposer une variable de modèle comme celle-ci et cela crée un moyen simple de créer un formulaire pour exécuter une requête basée sur sur quelques paramètres.
Voilà donc ce que j'ai pour la démo. Je vais revenir aux diapositives. Juste pour récapituler, nous avons montré comment un administrateur, un gouverneur de données, peut intervenir en plaçant des avertissements sur les objets qui apparaissent dans l'outil de requête, comment Alation utilise sa connaissance de l'utilisation des objets de données pour faire des suggestions intelligentes, comment cela apporte dans le profilage et d'autres conseils pour améliorer les flux de travail des analystes lorsqu'ils touchent à des objets particuliers, et comment tout ce type de flux revient dans le catalogue lorsque de nouvelles requêtes sont écrites.
Évidemment, je suis porte-parole au nom de l'entreprise. Je vais dire de belles choses sur les catalogues de données. Si vous voulez entendre directement l'un de nos clients, Kristie Allen de Safeway dirige une équipe d'analystes et a une histoire vraiment cool sur un moment où elle avait vraiment besoin de battre le temps pour livrer une expérience marketing et comment son ensemble L'équipe a utilisé Alation pour collaborer et se tourner très rapidement sur ce projet. Vous pouvez donc suivre ce lien bit.ly pour découvrir cette histoire, ou si vous souhaitez en savoir un peu plus sur la façon dont Alation pourrait intégrer un catalogue de données dans votre organisation, nous sommes heureux de mettre en place une démo personnalisée. Merci beaucoup.
Rebecca Jozwiak: Merci beaucoup, David. Je suis sûr que Dez et Robin ont quelques questions avant de passer aux questions et réponses du public. Dez, tu veux y aller en premier?
Dez Blanchfield: Absolument. J'adore l'idée de ce concept de requêtes publiées et de le relier à la source de la création. Je suis un champion de longue date de cette idée d'un magasin d'applications interne et je pense que c'est une très bonne base pour s'appuyer sur cela.
Je suis venu en quelque sorte pour avoir un aperçu de certaines des organisations que vous voyez faire cela, et quelques-unes des histoires de réussite qu'elles auraient pu avoir avec tout ce parcours consistant non seulement à tirer parti de votre outil et de votre plate-forme pour découvrir les données, mais puis également transformer leurs traits culturels et comportementaux internes autour. Ayant maintenant ce type de magasin d'applications interne où vous pouvez simplement télécharger, le concept où ils peuvent non seulement le trouver, mais ils peuvent en fait commencer à développer de petites communautés avec les gardiens de ces connaissances.
David Crawford: Oui, je pense que nous avons été surpris. Nous croyons en la valeur du partage des requêtes, à la fois de mon passé en tant que chef de produit Adtech et de tous les clients avec lesquels nous avons parlé, mais je suis toujours surpris de la fréquence à laquelle c'est l'une des toutes premières choses que les clients parler de la valeur qu'ils retirent d'Alation.
Je faisais des tests utilisateur de l'outil de requête chez l'un de nos clients appelé Invoice2go, et ils avaient un chef de produit qui était relativement nouveau, et ils ont dit - il m'a en fait dit, sans invite lors du test utilisateur, «Je ne le ferais pas écrire du SQL, sauf que cela est rendu facile par Alation. »Et bien sûr, en tant que PM, je me dis:« Que voulez-vous dire, comment avons-nous fait cela? »Et il a dit:« Eh bien, c'est vraiment juste parce que je peux me connecter et voir toutes ces requêtes existantes. "Commencer avec une liste vierge avec SQL est une chose incroyablement difficile à faire, mais modifier une requête existante où vous pouvez voir le résultat qui est sorti et vous pouvez dire, «Oh, j'ai juste besoin de cette colonne supplémentaire» ou «J'ai besoin de la filtrer sur une plage de dates particulière», c'est une chose beaucoup plus facile à faire.
Nous avons vu une sorte de ces rôles auxiliaires, comme les chefs de produit, peut-être des gens dans les opérations de vente, qui commencent à choisir et qui ont toujours voulu apprendre SQL et commencer à le récupérer en utilisant ce catalogue. Nous avons également vu que beaucoup d'entreprises ont essayé de faire une sorte d'open source. J'ai essayé de construire ce genre de choses en interne, où elles suivent les requêtes et les rendent disponibles, et il y a vraiment des défis de conception délicats pour les rendre utiles. Facebook a eu un outil interne qu'ils ont appelé HiPal qui a en quelque sorte capturé toutes les requêtes écrites sur Hive, mais ce que vous découvrez, c'est que si vous n'encouragez pas les utilisateurs de la bonne manière, vous vous retrouvez avec un très longue liste de déclarations sélectives. Et en tant qu'utilisateur qui essaie de comprendre si une requête est utile pour moi ou si elle est bonne, si je passe en revue une longue liste d'instructions sélectionnées, il me faudra beaucoup plus de temps pour obtenir quelque chose de valeur que à partir de zéro. Nous avons réfléchi assez attentivement à la façon de créer un catalogue de requêtes qui apporte les bonnes choses au premier plan et les fournit de manière utile.
Dez Blanchfield: Je pense que nous traversons tous ce parcours depuis le plus jeune âge jusqu'à l'âge adulte, à bien des égards. Un tas de technologies. Personnellement, j'ai moi-même vécu cette même chose authentique, comme apprendre à couper du code. Je parcourais des magazines, puis des livres, et j'étudiais à un certain niveau, puis je devais aller et en fait obtenir plus de formation et d'éducation.
Mais par inadvertance, j'ai constaté que même lorsque je devais m'enseigner et lire des magazines et lire des livres et couper les programmes des autres et les cours, je finissais toujours par apprendre autant de cours que de parler à d'autres des gens qui ont eu des expériences. Et je pense que c'est une découverte intéressante que, maintenant que vous apportez cela à l'analyse de données, nous voyons essentiellement ce même parallèle, que les êtres humains sont toujours assez intelligents.
L'autre chose que je tiens vraiment à comprendre est, à un niveau très élevé, que de nombreuses organisations vont demander: «Combien de temps faut-il pour arriver à ce point?» Quel est le point de basculement dans le temps lorsque les gens obtiennent votre plate-forme installée et ils ont commencé à découvrir les types d'outils? À quelle vitesse les gens voient-ils cette chose se transformer en un moment vraiment immédiat où ils se rendent compte qu'ils ne s'inquiètent même plus du retour sur investissement parce qu'il est là, mais maintenant ils changent en fait leur façon de faire des affaires ? Et ils ont découvert un art perdu et ils s'attendent à pouvoir en faire quelque chose de vraiment très amusant.
David Crawford: Oui, je peux y revenir un peu. Je pense que lorsque nous sommes installés, l'une des bonnes choses, l'une des choses que les gens aiment à propos d'un catalogue qui est directement connecté aux systèmes de données, c'est que vous ne commencez pas vierge où vous devez le remplir page par page. Et cela est un peu vrai des solutions de données précédentes où vous commenciez avec un outil vide et vous devez commencer à créer une page pour tout ce que vous souhaitez documenter.
Étant donné que nous documentons tant de choses automatiquement en extrayant les métadonnées, essentiellement dans les quelques jours suivant l'installation du logiciel, vous pouvez avoir une image de votre environnement de données qui est d'au moins 80% dans l'outil. Et puis je pense que dès que les gens commencent à écrire des requêtes avec l'outil, ils sont automatiquement sauvegardés dans le catalogue, et donc ils commencent également à apparaître.
Je ne veux pas être trop impatient de le dire. Je pense que deux semaines est une assez bonne estimation prudente, à un mois. Deux semaines à un mois, une estimation prudente de vraiment se retourner et de se sentir comme si vous en tiriez de la valeur, comme si vous commenciez à partager certaines connaissances et à pouvoir y aller et découvrir des choses sur vos données.
Dez Blanchfield: C'est assez étonnant, vraiment, quand on y pense. Le fait que certaines des grandes plates-formes de données que vous indexez et cataloguez efficacement mettent parfois jusqu'à un an pour être implémentées, déployées et prises en charge correctement.
La dernière question que j'ai à vous poser avant de passer à Robin Bloor, ce sont les connecteurs. L'une des choses qui me saute immédiatement aux yeux est que vous avez évidemment tout ce défi réglé. Il y a donc quelques questions très rapidement. Premièrement, à quelle vitesse les connecteurs sont-ils mis en œuvre? Évidemment, vous commencez avec la plus grande plate-forme, comme les Oracles et les Teradatas et ainsi de suite et les DB2. Mais à quelle fréquence voyez-vous de nouveaux connecteurs arriver, et quel délai d'exécution prennent-ils? J'imagine que vous avez un cadre standard pour eux. Et jusqu'où allez-vous en profondeur? Par exemple, les Oracles et IBM du monde, et même Tereadata, puis certaines des plates-formes open source les plus populaires. Travaillent-ils directement avec vous? Le découvrez-vous vous-même? Devez-vous avoir des connaissances internes sur ces plateformes?
À quoi ressemble le développement d'un connecteur, et à quel degré vous impliquez-vous dans ces partenariats pour vous assurer que ces connecteurs découvrent tout ce que vous pouvez?
David Crawford: Oui, bien sûr, c'est une excellente question. Je pense que pour la plupart, nous pouvons développer les connecteurs. Nous l'avons certainement fait lorsque nous étions une jeune startup et que nous n'avions pas de clients. Nous pouvons certainement développer les connexions sans avoir besoin d'un accès interne. Nous n'obtenons jamais un accès spécial aux systèmes de données qui ne sont pas accessibles au public, et souvent sans avoir besoin d'informations privilégiées. Nous profitons des services de métadonnées disponibles par les systèmes de données eux-mêmes. Souvent, ceux-ci peuvent être assez complexes et difficiles à travailler. Je connais SQL Server en particulier, la façon dont ils gèrent le journal des requêtes, il y a plusieurs configurations différentes et c'est quelque chose que vous devez vraiment travailler. Vous devez comprendre les nuances et les boutons et cadrans dessus pour le configurer correctement, et c'est quelque chose que nous travaillons avec les clients depuis que nous l'avons fait plusieurs fois auparavant.
Mais dans une certaine mesure, c'est le type d'API publiques disponibles ou d'interfaces publiques disponibles que nous exploitons. Nous avons des partenariats avec plusieurs de ces entreprises, ce qui est principalement un motif de certification, afin qu'elles se sentent à l'aise de dire que nous travaillons et qu'elles peuvent également nous fournir des ressources pour les tests, parfois un accès anticipé peut-être à une plate-forme qui sort pour s'assurer que nous travaillons sur les nouvelles versions.
Pour rétablir une nouvelle connexion, je dirais encore une fois, en essayant d'être conservateur, disons six semaines à deux mois. Cela dépend de sa similitude. Ainsi, certains travaux de Postgre sont très similaires à Redshift. Redshift et Vertica partagent beaucoup de leurs détails. Nous pouvons donc profiter de ces choses. Mais oui, six semaines à deux mois seraient justes.
Nous avons également des API, de sorte que - nous considérons Alation comme une plate-forme de métadonnées également, donc si rien n'est disponible pour nous de tendre la main et de saisir automatiquement, il existe des moyens que vous pouvez écrire le connecteur vous-même et le pousser dans notre système afin que tout est toujours centralisé dans un seul moteur de recherche.
Dez Blanchfield: Fantastique. Je l'apprécie. Nous allons donc céder la parole à Robin, car je suis sûr qu'il a aussi une pléthore de questions. Robin?
Rebecca Jozwiak: Robin est peut-être en sourdine.
Dez Blanchfield: Vous vous êtes mis en sourdine.
Robin Bloor: Oui, c'est ça. Désolé, je me suis mis en sourdine. Lorsque vous implémentez cela, quel est le processus? Je suis un peu curieux car il peut y avoir beaucoup de données dans de nombreux endroits. Alors, comment ça marche?
David Crawford: Oui, bien sûr. Nous entrons, d'abord c'est une sorte de processus informatique pour s'assurer que notre serveur est provisionné, pour s'assurer que les connexions réseau sont disponibles, que les ports sont ouverts afin que nous puissions réellement accéder aux systèmes. Ils savent tous souvent avec quels systèmes ils veulent commencer. Connaître l'intérieur d'un système de données, ce qui - et parfois nous allons réellement les aider. Nous allons les aider à jeter un premier coup d'œil à leur journal de requêtes pour comprendre qui utilise quoi et combien d'utilisateurs ils ont sur un système. Nous allons donc vous aider à savoir où - souvent, si des centaines ou des milliers de personnes peuvent se connecter à des bases de données, ils ne savent pas vraiment où ils se connectent, nous pouvons donc découvrir journaux de requêtes combien de comptes d'utilisateurs uniques avez-vous réellement vous connectant et exécutant des requêtes ici dans un mois environ.
Nous pouvons donc en profiter, mais souvent uniquement sur les plus importants. Nous les mettons en place et ensuite il y a un processus qui consiste à dire: "Priorisons." Il existe une gamme d'activités qui peuvent se dérouler en parallèle. Je me concentrerais sur la formation à l'utilisation de l'outil de requête. Une fois que les gens commencent à utiliser l'outil de requête, tout d'abord, beaucoup de gens adorent le fait qu'il ne s'agit que d'une interface unique pour tous leurs différents systèmes. Ils aiment également le fait qu'il soit basé sur le Web, n'implique aucune installation s'ils ne le souhaitent pas. Du point de vue de la sécurité, ils aiment avoir une sorte de point d'entrée unique, du point de vue du réseau, entre une sorte de réseau informatique d'entreprise et le centre de données où vivent les sources de données de production. Et donc, ils vont configurer Alation comme outil de requête et commencer à utiliser Compose comme point d'accès pour tous ces systèmes.
Donc, une fois que cela se produit, nous nous concentrons sur la formation, c'est de comprendre quelles sont les différences entre un outil de requête basé sur le Web ou sur un serveur par rapport à celui que vous auriez sur votre bureau, et certaines des nuances de l'utilisation cette. Et en même temps, ce que nous essaierons de faire est d'identifier les données les plus précieuses, en profitant à nouveau des informations du journal des requêtes et en disant: «Hé, vous voudrez peut-être entrer et aider les gens à les comprendre. Commençons à publier des requêtes représentatives sur ces tables. »C'est parfois le moyen le plus efficace pour faire tourner très rapidement les gens. Examinons votre propre historique de requêtes, publions ces éléments afin qu'ils s'affichent en tant que premières requêtes. Lorsque les utilisateurs consultent une page de table, ils peuvent voir toutes les requêtes qui ont touché cette table et commencer à partir de là. Et puis commençons à ajouter des titres et des descriptions à ces objets afin qu'ils soient plus faciles à trouver et à rechercher, afin que vous connaissiez certaines des nuances de la façon de les utiliser.
Nous nous assurons que nous obtenons un examen approfondi du journal des requêtes afin de pouvoir générer une lignée. L'une des choses que nous faisons est de parcourir le journal des requêtes à des moments où les données se déplacent d'une table à une autre, et cela nous permet de poser l'une des questions les plus fréquemment posées sur une table de données: d'où cela vient-il? Comment puis-je lui faire confiance? Et donc ce que nous pouvons montrer n'est pas seulement de quelles autres tables il est issu, mais comment il a été transformé en cours de route. Encore une fois, cela est en quelque sorte alimenté par le journal des requêtes.
Nous nous assurons donc que ces éléments sont configurés et que nous intégrons la lignée dans le système, et nous ciblons les éléments de métadonnées les plus précieux et les plus exploités que nous pouvons établir sur les pages du tableau, afin que lorsque vous recherchez, vous trouvez quelque chose d'utile.
Robin Bloor: D'accord. L'autre question - il y a beaucoup de questions de l'auditoire, donc je ne veux pas prendre trop de temps ici - l'autre question qui me vient à l'esprit est, juste les points douloureux. Beaucoup de logiciels sont achetés parce que les gens ont, d'une manière ou d'une autre, des difficultés avec quelque chose. Alors, quel est le point commun de la douleur qui conduit les gens à Alation?
David Crawford: Ouais. Je pense qu'il y en a quelques-uns, mais je pense que l'un de ceux que nous entendons assez souvent est l'intégration des analystes. «Je vais devoir embaucher 10, 20, 30 personnes à court terme qui vont devoir produire de nouvelles informations à partir de ces données, comment vont-elles se mettre à niveau?» Donc, l'intégration des analystes est quelque chose que nous avons certainement tacle. Cela permet également de soulager les analystes principaux de passer tout leur temps à répondre aux questions des autres sur les données. C'est aussi très fréquent. Et ces deux sont essentiellement des problèmes d'éducation.
Et puis je dirais qu'un autre endroit que nous voyons les gens adopter Alation est quand ils veulent mettre en place un nouvel environnement de données pour que quelqu'un travaille. Ils veulent faire de la publicité et le commercialiser en interne pour que les gens puissent en profiter. Faire de Alation l'interface de ce nouvel environnement analytique est donc très attrayant. Il y a la documentation, il y a un seul point d'introduction au - un seul point d'accès aux systèmes, et c'est donc un autre endroit où les gens viendront nous voir.
Robin Bloor: D'accord, je vais vous transmettre à Rebecca parce que le public essaie de vous joindre.
Rebecca Jozwiak: Oui, nous avons beaucoup de bonnes questions d'audience ici. Et David, celui-ci vous a été spécifiquement posé. Cela vient de quelqu'un qui a apparemment une certaine expérience avec les gens qui abusent des requêtes, et il dit en quelque sorte que plus nous habilitons les utilisateurs, plus il est difficile de gouverner l'utilisation responsable des ressources de calcul. Pouvez-vous donc vous défendre contre la propagation d'expressions de requête erronées mais courantes?
David Crawford: Oui, je vois cette question. C'est une excellente question - une que nous recevons assez fréquemment. J'ai moi-même vu la douleur dans les entreprises précédentes, où vous devez former les utilisateurs. Par exemple, «Il s'agit d'une table de journaux, elle contient des journaux remontant à des années. Si vous allez écrire une requête sur cette table, vous devez vraiment limiter par date. »Ainsi, par exemple, c'est une formation que j'ai suivie dans une entreprise précédente avant d'avoir accès à la base de données.
Nous essayons de résoudre ce problème de deux façons. Je dirais que je pense que les données du journal des requêtes sont vraiment très utiles pour y remédier. Il donne un autre aperçu par rapport à ce que la base de données fait en interne avec son planificateur de requêtes. Et ce que nous faisons, c'est une de ces interventions - nous avons les interventions manuelles que j'ai montrées, et c'est utile, non? Ainsi, sur une jointure particulière, par exemple, vous pouvez dire: «Déprécions cela». Il aura un gros drapeau rouge lorsqu'il apparaîtra dans la suggestion intelligente. C'est donc une façon d'essayer de toucher les gens.
Une autre chose que nous faisons est automatisée lors des interventions au moment de l'exécution. Cela utilisera en fait l'arborescence d'analyse de la requête avant de l'exécuter pour voir, cela inclut-il un certain filtre ou quelques autres choses que nous faisons là aussi. Mais l'un des plus précieux et le plus simple à expliquer est, comprend-il un filtre? Donc, comme cet exemple que je viens de donner, cette table de journal, si vous voulez l'interroger, doit avoir une plage de dates, vous pouvez spécifier dans la page du tableau là-bas que vous imposez l'application de ce filtre de plage de dates. Si quelqu'un essaie d'exécuter une requête qui n'inclut pas ce filtre, cela l'arrêtera en fait avec un gros avertissement et il dira: "Vous devriez probablement ajouter du SQL qui ressemble à ceci à votre requête." Ils peuvent continuer si Ils veulent. Nous n'allons pas les interdire complètement de l'utiliser - c'est aussi une requête, il faut, en fin de compte, exécuter des requêtes. Mais nous mettons une barrière assez grande devant eux et nous leur donnons une suggestion, une suggestion concrète applicable pour modifier la requête afin d'améliorer leurs performances.
En fait, nous le faisons aussi automatiquement dans certains cas, encore une fois en observant le journal des requêtes. Si nous constatons qu'un pourcentage vraiment élevé de requêtes sur cette table tirent parti d'un filtre particulier ou d'une clause de jointure particulière, alors nous le verrons apparaître. Nous allons promouvoir cela à une intervention. En fait, cela m'est arrivé sur un ensemble de données internes. Nous avons des données client et nous avons des ID utilisateur, mais l'ensemble d'ID utilisateur, car c'est en quelque sorte - nous avons des ID utilisateur pour chaque client. Ce n'est pas unique, vous devez donc le coupler avec un ID client afin d'obtenir une clé de jointure unique. Et j'écrivais une requête et j'ai essayé d'analyser quelque chose et elle est apparue et a dit: «Hé, tout le monde semble joindre ces tables avec à la fois l'ID client et l'ID utilisateur. Êtes-vous sûr de ne pas vouloir faire ça? »Et cela m'a en fait empêché de faire une analyse incorrecte. Cela fonctionne donc à la fois pour la précision de l'analyse et pour les performances. Voilà donc comment nous abordons ce problème.
Rebecca Jozwiak: Cela me semble efficace. Vous avez dit que vous n'empêcherez pas nécessairement les gens de monopoliser les ressources, mais leur apprenez en quelque sorte que ce qu'ils font n'est peut-être pas le meilleur, n'est-ce pas?
David Crawford: Nous supposons toujours que les utilisateurs ne sont pas malveillants - donnez-leur les meilleures intentions - et nous essayons d'être assez ouverts de cette façon.
Rebecca Jozwiak: D'accord. Voici une autre question: «Quelle est la différence entre un gestionnaire de catalogue, comme avec votre solution, et un outil MDM? Ou repose-t-il réellement sur un principal différent en élargissant le choix des tables de requête, alors que MDM le ferait automatiquement, mais avec le même principal sous-jacent de collecte de métadonnées. "
David Crawford: Oui, je pense que lorsque je regarde les solutions MDM traditionnelles, la principale différence est d'ordre philosophique. Tout dépend de l'utilisateur. Un peu comme je l'ai dit au début de ma présentation, Alation, je pense que lorsque nous avons été fondés, nous avons été fondés dans le but de permettre aux analystes de produire plus d'informations, de les produire plus rapidement, d'être plus précis dans les informations qu'ils produire. Je ne pense pas que cela ait jamais été l'objectif d'une solution MDM traditionnelle. Ces solutions ont tendance à viser les personnes qui doivent produire des rapports sur les données qui ont été saisies au CCN ou en interne à d'autres fins d'audit. Cela peut parfois permettre aux analystes, mais c'est plus souvent, si cela va permettre à un praticien dans son travail, il est plus susceptible d'activer un architecte de données comme un DBA.
Lorsque vous pensez aux choses du point de vue d'un analyste, c'est à ce moment que vous commencez à créer un outil de requête qu'un outil MDM ne ferait jamais. C'est à ce moment que vous commencez à penser aux performances ainsi qu'à la précision, ainsi qu'à comprendre quelles données sont liées aux besoins de mon entreprise. Toutes ces choses sont des choses qui nous viennent à l'esprit lorsque nous concevons l'outil. Il va dans nos algorithmes de recherche, il va dans la mise en page des pages du catalogue et la capacité à apporter des connaissances de toute l'organisation. Cela tient au fait que nous avons construit l'outil de requête et que nous y avons directement intégré le catalogue, donc je pense que cela vient vraiment de cela. Quel utilisateur pensez-vous en premier?
Rebecca Jozwiak: D'accord, très bien. Cela a vraiment aidé à l'expliquer. qui mourait d'envie de mettre la main sur les archives parce qu'il devait partir, mais il voulait vraiment que sa question reçoive une réponse. Il a dit qu'il a été mentionné au début qu'il existe plusieurs langues, mais SQL est-il le seul langage exploité dans le composant Compose?
David Crawford: Oui, c'est vrai. Et l'une des choses que j'ai remarquées, comme j'ai été témoin de l'explosion des différents types de bases de données, de bases de données de documents, de bases de données graphiques, de magasins de valeurs clés, c'est qu'elles sont vraiment puissantes pour les développements d'applications. Ils peuvent très bien répondre à des besoins particuliers, mieux que les bases de données relationnelles.
Mais lorsque vous le ramenez à l'analyse des données, lorsque vous le ramenez à - lorsque vous souhaitez fournir ces informations aux personnes qui vont faire des rapports ad hoc ou creuser ad hoc dans les données, elles reviennent toujours à une relationnelle, au moins, l'interface pour les humains. C'est en partie parce que SQL est la lingua franca de l'analyse des données, ce qui signifie que, pour les humains, c'est aussi pour les outils qui s'intègrent. Je pense que c'est la raison pour laquelle SQL sur Hadoop est si populaire et il y a tellement de tentatives pour le résoudre, parce qu'en fin de compte, c'est ce que les gens savent. Il y a probablement des millions de personnes qui savent comment écrire du SQL, et je ne m'aventurerais pas des millions qui savent comment écrire une requête de structure de pipeline d'agrégation Mongo. Et qu'il s'agit d'un langage standard utilisé pour l'intégration sur une très grande variété de plateformes. Donc, tout ce qui veut dire, on nous demande très rarement d'aller en dehors, car c'est l'interface que la plupart des analystes utilisent, et c'est un endroit où nous nous sommes concentrés, en particulier dans Compose, que nous nous sommes concentrés sur l'écriture de SQL.
Je dirais que la science des données est l'endroit où ils s'aventurent le plus à l'extérieur, et nous recevons donc parfois des questions sur l'utilisation de Pig ou SAS. Ce sont des choses que nous ne traitons certainement pas dans Compose et que nous aimerions saisir dans le catalogue. Et je vois aussi R et Python. Nous avons créé plusieurs interfaces pour utiliser les requêtes écrites dans Alation à l'intérieur des scripts R et Python, donc, puisque souvent lorsque vous êtes un data scientist et que vous travaillez dans un langage de script, votre les données source se trouvent dans une base de données relationnelle. Vous commencez avec une requête SQL, puis vous la traitez plus loin et créez des graphiques à l'intérieur de R et Python. Et nous avons créé des packages que vous pouvez importer dans ces scripts qui tirent les requêtes ou les résultats de requête d'Alation afin que vous puissiez y avoir un flux de travail mixte.
Rebecca Jozwiak: D'accord, parfait . Je sais que nous avons dépassé un peu le sommet de l'heure, je vais juste poser une ou deux questions de plus. Je sais que vous avez parlé de tous les différents systèmes auxquels vous pouvez vous connecter, mais en ce qui concerne les données hébergées en externe et les données hébergées en interne, cela peut-il être recherché ensemble dans votre vue unique, dans votre plate-forme unique?
David Crawford: Certainement. Il y a plusieurs façons de procéder. Je veux dire, hébergé en externe, j'imagine, j'essaie de penser exactement à ce que cela pourrait signifier. Cela pourrait signifier une base de données que quelqu'un héberge dans AWS pour vous. Cela pourrait signifier une source de données publique de data.gov. Nous nous connectons directement aux bases de données en nous connectant comme une autre application avec, avec un compte de bases de données, et c'est ainsi que nous extrayons les métadonnées. Donc, si nous avons un compte et que nous avons un port réseau ouvert, nous pouvons y accéder. Et puis quand nous n'avons pas ces choses, nous avons quelque chose appelé une source de données virtuelle, qui vous permet essentiellement de pousser la documentation, que ce soit automatiquement, en écrivant votre propre connecteur, ou en le remplissant en faisant même comme un téléchargement CSV, pour documenter les données à côté de vos données internes. Tout cela est placé dans le moteur de recherche. Il devient référencable à l'intérieur des articles et autres documents et conversations à l'intérieur du système. C'est ainsi que nous gérons lorsque nous ne pouvons pas nous connecter directement à un système.
Rebecca Jozwiak: D'accord, c'est logique. Je vais juste vous poser une autre question. Un participant est demandant: «Comment le contenu d'un catalogue de données doit-il être validé, vérifié ou maintenu, lorsque les données source sont mises à jour, que les données source sont modifiées, etc.»
David Crawford: Oui, c'est une question que nous recevons beaucoup, et je pense que l'une des choses que nous - une de nos philosophies, comme je l'ai dit, nous ne pensons pas que les utilisateurs sont malveillants. Nous supposons qu'ils essaient d'apporter les meilleures connaissances. Ils n'entreront pas et induiront délibérément les gens en erreur au sujet des données. Si c'est un problème dans votre organisation, Alation n'est peut-être pas le bon outil pour vous. Mais si vous présumez de bonnes intentions de la part des utilisateurs, alors nous pensons à cela comme quelque chose où, les mises à jour entrent en jeu, puis généralement ce que nous faisons est de mettre un responsable en charge de chaque objet de données ou de chaque section des données. Et nous pouvons informer ces administrateurs lorsque des modifications sont apportées aux métadonnées et ils peuvent les gérer de cette manière. Ils voient les mises à jour arriver, ils les valident. S'ils n'ont pas raison, ils peuvent revenir en arrière et les modifier et les informer et, espérons-le, même contacter l'utilisateur qui a fourni les informations et les aider à apprendre.
C'est donc la principale façon dont nous pensons le faire. Ce genre de suggestion par la foule et la gestion par les stadiers, nous avons donc certaines capacités à cet égard.
Rebecca Jozwiak: D'accord, très bien. Et si vous pouviez simplement faire savoir aux gens comment ils peuvent mieux démarrer avec Alation, et où peuvent-ils aller spécifiquement pour obtenir plus d'informations. Je sais que vous l'avez partagé un peu. Est-ce le meilleur endroit?
David Crawford: Alation.com/learnmore Je pense que c'est une excellente façon de procéder. Pour vous inscrire à une démonstration, le site Alation.com propose de nombreuses ressources, des livres blancs sur les clients et des informations sur notre solution. Je pense donc que c'est un excellent point de départ. Vous pouvez également envoyer un e-mail.
Rebecca Jozwiak: D'accord, parfait . Et je sais, participants, désolé si je n'ai pas répondu à toutes les questions aujourd'hui, mais sinon, elles seront transmises à David ou à son équipe de vente ou à quelqu'un chez Alation, afin qu'ils puissent certainement vous aider à répondre à vos questions et à comprendre ce que fait Alation ou ce qu'il fait de mieux.
Et avec ça, les gars, je vais aller de l'avant et nous signer. Vous pouvez toujours trouver les archives sur InsideAnalysis.com. Vous pouvez également le trouver sur Techopedia.com. Ils ont tendance à se mettre à jour un peu plus rapidement, alors vérifiez-le. Et merci beaucoup à David Crawford, Dez Blanchfield et Robin Boor aujourd'hui. Ce fut une excellente webdiffusion. Et avec ça, je vais vous dire adieu. Merci les amis. Bye Bye.
David Crawford: Merci.
