La clé de la qualité Analyse de données volumineuses: comprendre les différences - Transcription TechWise Episode 4

Auteur: Roger Morrison
Date De Création: 17 Septembre 2021
Date De Mise À Jour: 21 Juin 2024
Anonim
La clé de la qualité Analyse de données volumineuses: comprendre les différences - Transcription TechWise Episode 4 - La Technologie
La clé de la qualité Analyse de données volumineuses: comprendre les différences - Transcription TechWise Episode 4 - La Technologie

Contenu


Source: Jakub Jirsak / Dreamstime.com

À emporter:

Eric Kavanagh, animateur, discute de l'analyse de données volumineuses avec des experts du secteur.

Eric: Mesdames et messieurs, nous sommes en fin d'année 2014, du moins presque. C’est notre dernière diffusion Web de l’année! Bienvenue chez TechWise! Oui en effet! Je m'appelle Eric Kavanagh. Je serai votre modérateur pour un webcast génial, les gars. Je suis vraiment très excité. Nous avons deux formidables analystes en ligne et deux grandes entreprises, de véritables innovateurs dans cet écosystème du Big Data. Et nous allons parler de la clé de l’analyse du Big Data, c’est comprendre la différence. Alors, allons-y et plongez dans l’esprit, chers amis.


Nous avons plusieurs présentateurs. Comme vous pouvez le constater, le vôtre est vraiment au sommet. Mike Ferguson appelle depuis le Royaume-Uni, où il a dû obtenir des privilèges spéciaux pour rester dans l'immeuble de son bureau aussi tard. C’est tard pour lui. Nous avons le Dr Robin Bloor, notre propre analyste en chef du groupe Bloor. Nous aurons également George Corugedo, PDG et cofondateur de RedPoint Global, et Keith Renison, architecte principal des solutions de SAS Institute. Ce sont des entreprises fantastiques. Ce sont des entreprises qui innovent vraiment. Et nous allons explorer quelques-uns des avantages de ce qui se passe actuellement dans le monde du big data. Et regardons les choses en face, les petites données n’ont pas disparu. Et à cela, laissez-moi vous résumer mon résumé ici.



Donc, il y a une vieille expression française: "Plus les choses changent, plus elles restent les mêmes." Et voyons quelques faits ici: le Big Data ne résoudra pas le problème des petites données. Les petites données d'entreprise sont toujours disponibles. C’est toujours partout. C’est le carburant des opérations de l’économie de l’information d’aujourd’hui. Et les mégadonnées complètent ces données dites petites, mais ne les supplantent pas. Il va toujours y avoir. J'aime beaucoup de choses sur le Big Data, en particulier les données générées par machine.


Et aujourd’hui, nous allons probablement parler un peu des données des médias sociaux, qui sont également très puissantes. Et si vous pensez, par exemple, à quel point le social a changé les affaires, il suffit de penser à trois sites Web rapides: LinkedIn et. Pensez au fait qu’il ya cinq ans, personne ne faisait ce genre de choses. est un mastodonte absolu ces jours-ci. , bien sûr, est énorme. C’est gigantesque. Et puis, LinkedIn est le standard de facto pour les réseaux et la communication d’entreprise. Ces sites sont gigantesques et pour pouvoir exploiter les données qu’ils contiennent, ils vont faire revivre certaines fonctionnalités révolutionnaires. Cela va vraiment faire beaucoup de bien à beaucoup d’organisations, du moins à celles qui en profitent.



Pas de bugs, pas de stress - Votre guide étape par étape pour créer un logiciel qui change la vie sans vous détruire

Vous ne pouvez pas améliorer vos compétences en programmation lorsque personne ne se soucie de la qualité des logiciels.

Ainsi, la gouvernance - la gouvernance compte toujours. Encore une fois, le Big Data n’annule pas le besoin de gouvernance. Franchement, il existe un tout nouveau besoin de se concentrer sur la manière de gouverner le monde du Big Data. Comment vous assurez-vous que vos procédures et vos politiques sont en place? que les bonnes personnes ont accès aux bonnes données; que vous avez des contacts, vous avez une lignée impliquée ici? En fait, vous savez d'où proviennent les données et ce qui leur est arrivé. Et tout cela change.


Franchement, je suis vraiment très impressionné par ce que j’ai vu dans ce nouveau monde qui exploite l’écosystème Hadoop, qui est bien sûr bien plus que du stockage en termes de fonctionnalité. Hadoop est également un moteur de calcul. Et la société doit trouver comment exploiter cette puissance de calcul, cette capacité de traitement parallèle. Ils vont faire des choses vraiment très cool. Nous allons apprendre à ce sujet aujourd'hui.


L’autre chose à mentionner, c’est une chose dont M. Bloor a récemment parlé, est que la vague d’innovation n’est pas terminée. Nous avons donc beaucoup retenu l'attention autour de Hadoop. Nous avons vu des entreprises comme Cloudera et Hortonworks, vous savez, vraiment faire des vagues. Et franchement, ils développent des partenariats avec les entreprises qui répondent à l’appel d’aujourd’hui. Et ils développent des partenariats avec beaucoup de gens. Mais la vague d'innovation n'est pas terminée. De plus en plus de projets issus de la fondation Apache sont en train de changer non seulement le point final, les applications utilisées par les utilisateurs, mais également l'infrastructure elle-même.


Donc, tout ce développement de YARN - encore un autre négociateur de ressources - est vraiment un système d’exploitation pour le Big Data. Et c’est une grosse affaire. Nous allons donc apprendre comment cela change aussi les choses. Donc, juste quelques conseils évidents ici, méfiez-vous des longs contrats, vous savez, les contrats de cinq ou dix ans seront la vague, la voie qui me semble. Vous allez vouloir éviter le blocage à tout prix. Nous allons en apprendre davantage sur tout cela aujourd'hui.


Notre premier analyste a donc pris la parole aujourd’hui. Notre premier orateur de l’ensemble du programme est Mike Ferguson, originaire du Royaume-Uni. Sur ce, je vais vous remettre les clés, Mike, et vous laisser les prendre. Mike Ferguson, la parole est à vous.


Mike, t'es là? Vous êtes peut-être muet. Je ne l’entends pas. Nous devrons peut-être le rappeler. Et nous allons passer directement aux diapositives de Robin Bloor. Robin, je vais placer le rang sur le pauvre Mike Ferguson ici. Je vais y aller une seconde.


C'est toi, Mike? Pouvez-vous nous entendre? Nah. Je pense que nous allons devoir y aller et aller avec Robin en premier. Alors, attendez une seconde, mes amis. Je vais tirer quelques liens vers les diapositives ici dans quelques minutes également. Alors, laissez-moi remettre les clés à Robin Bloor. Robin, tu peux commencer en premier au lieu de Mike et je l’appellerai dans une seconde.


Robin: D'accord.


Eric: Attends, Rob. Laissez-moi aller chercher votre diapositive ici, Rob. Cela va prendre une seconde.


Robin: D'accord.


Eric: Ouais. Vous pouvez en quelque sorte parler de ce dont nous traitons ici, en termes de gouvernance. Je sais que vous allez parler de gouvernance. Cela est généralement pris en compte dans le problème des petites données d’entreprise. Alors maintenant, j'ai la diapositive, Robin. Ne bouge rien. Et voilà. La parole est à vous. Emportez-le.


Robin: D'accord. Ouais. Je veux dire, eh bien, nous avions en quelque sorte convenu au préalable que Mike parlerait de l’analyse, et je parlerai de la gouvernance. Dans une certaine mesure, la gouvernance suit l’analyse en ce sens que c’est une des raisons pour lesquelles vous utilisez le Big Data, et la raison pour laquelle vous assemblez tous les logiciels nécessaires à l’analyse est la valeur.


Il y a un problème. Et le problème est que, vous savez, les données doivent être discutées. Les données doivent être marshalées. Les données doivent être rassemblées et gérées de manière à permettre l’analyse en toute confiance - je suppose, c’est le mot. Je pensais donc que c’était l’aspect gouvernance de l’équation. La chose à dire, vraiment, c'est que, vous savez, la gouvernance était déjà un problème. La gouvernance était déjà un problème, et cela commence à devenir un problème dans l'ensemble du jeu de l'entrepôt de données.


Ce qui s’est réellement passé, c’est devenu un problème beaucoup plus vaste. Et la raison pour laquelle il est devenu un problème beaucoup plus vaste ainsi que plus de données, mais je veux dire, ce sont les raisons, vraiment. Le nombre de sources de données a considérablement augmenté. Auparavant, les sources de données dont nous disposions étaient généralement définies par ce qui alimentait l'entrepôt de données. L'entrepôt de données serait normalement alimenté par les systèmes RTP. C’est possible un peu de données externes, pas beaucoup.


Nous sommes maintenant dans un monde où, comme vous le savez, un marché des données est en train de naître et par conséquent, il y aura un commerce de données. Vous avez déjà des charges et des charges de différentes sources de données en continu que vous pouvez réellement importer dans l'organisation. Nous avons des données de médias sociaux qui les ont prises, prises pour son propre compte, pour ainsi dire. Je veux dire, énormément, la valeur des sites de médias sociaux réside dans les informations qu’ils rassemblent et peuvent donc mettre à la disposition des gens.


Nous avons également découvert, vous savez, c’est comme si elles existaient déjà. Nous avions déjà ces fichiers journaux, vous savez, avec l’avènement de Splunk. Et bientôt, il est devenu évident qu’un fichier journal a une valeur. Il y avait donc des données au sein de l'organisation - que nous pourrions appeler de nouvelles sources de données ainsi que des sources externes. Donc, c’est une chose. Et cela signifie vraiment que, quelles que soient les règles de gestion des données que nous avions auparavant, elles devront être étendues, d'une manière ou d'une autre, et continueront à être étendues pour régir réellement la Les données. Mais nous commençons maintenant à nous réunir d’une manière ou d’une autre.


Et en descendant cette liste, nous avons le streaming et la vitesse d’arrivée des données. Je pense que l’une des raisons de la popularité de Hadoop est qu’elle peut très bien être utilisée pour collecter de nombreuses données. Il peut également absorber la vitesse de transmission des données. Si vous n’avez pas besoin de l’utiliser immédiatement, c’est un environnement parallèle formidable et gigantesque. Mais vous avez également le fait qu’il y a pas mal d’analyses en continu en cours. C’était autrefois le secteur bancaire qui s’intéressait au streaming d’applications, mais c’est maintenant devenu un peu mondial. Et tout le monde cherche à diffuser les applications en continu d’une manière ou d’une autre, un moyen potentiel de tirer parti des données et de l’analyse pour l’organisation.


Nous avons les données non structurées. Les statistiques, qui représentent généralement 10% seulement des données mondiales, se trouvaient dans des bases de données relationnelles. L’une des principales raisons de cette situation tient au fait qu’elle était en fait peu structurée et qu’elle était en grande partie accessible sur le Web, mais assez éparpillée sur divers sites Web. Ces données se sont révélées être également analysables et utilisables. Et avec l'avènement de la technologie Symantec, qui s'introduit progressivement dans la situation, commence à le devenir.Il est donc nécessaire de rassembler et de gérer des données non structurées, ce qui signifie qu’elles sont beaucoup plus volumineuses qu’avant. Nous avons déjà des données sociales que j'ai déjà mentionnées, mais le point principal à ce sujet est qu'il faut probablement les nettoyer.


Nous avons les données de l'Internet des objets. C’est une sorte de situation différente. Il y aura probablement beaucoup de cela, mais beaucoup devra rester distribué quelque part près de l’endroit où il se trouve. Mais vous allez également vouloir, d’une manière ou d’une autre, y avoir recours pour effectuer l’analyse au sein de l’organisation sur les données. Donc, cela ajoute un autre facteur. Et ces données seront structurées différemment, car elles seront probablement - au format JSON ou XML, afin qu’elles se déclarent elles-mêmes. Et pas seulement, d’une manière ou d’une autre, que nous extrayons des données et que nous sommes capables de faire un type de schéma à la lecture de cette donnée particulière.


Nous avons la question de la provenance et il s’agit d’un problème d’analyse. Les résultats de toute analyse que vous effectuez sur des données ne peuvent pas être - si vous préférez - approuvés, considérés comme valides, à moins que vous ne connaissiez la provenance des données. Je veux dire, c’est juste du professionnalisme en termes d’activité des scientifiques de données. Mais vous savez, pour avoir la provenance des données, cela signifie que nous devons gouverner les données et conserver une note sur leur lignée.


Nous avons le problème de la puissance informatique et des parallèles et tout ce que cela fait, c'est que tout va plus vite. Le problème est qu’il est évident que certains processus que nous avons mis en place risquent d’être trop lents pour tout le reste. Donc, il y a peut-être des inadéquations en termes de vitesse.


Nous avons eu l'avènement de l'apprentissage automatique. L'apprentissage automatique a vraiment pour effet de faire de l'analyse un jeu différent de celui qu'elle était auparavant. Mais vous ne pouvez vraiment l'utiliser que si vous en avez le pouvoir.


Nous avons eu le fait de nouvelles charges de travail analytiques. Nous avons un monde parallèle et certains algorithmes analytiques doivent être exécutés en parallèle pour obtenir un effet maximal. Par conséquent, le problème est de savoir comment, d’une manière ou d’une autre, vous déplacez les données, les créez si elles sont disponibles. Et où vous exécutez réellement les charges de travail analytiques, car vous le faites peut-être dans la base de données. Donc, vous pouvez le faire dans des applications analytiques.


Il y a donc toute une série de défis en matière de gouvernance. Ce que nous avons fait cette année - la recherche que nous avons faite cette année portait vraiment sur l’architecture du Big Data. Et lorsque nous essayons de le généraliser, la conclusion à laquelle nous sommes arrivés - le diagramme que nous avons élaboré ressemblait beaucoup à ceci.


Je ne vais pas entrer dans les détails, d’autant plus que Mike fera beaucoup sur l’architecture des données pour l’analyse. Mais ce que j'aime vraiment, c'est que les gens se concentrent uniquement sur cette zone inférieure où nous rassemblons, d'une manière ou d'une autre, des données. J'aimerais mentionner quelque chose, à savoir la raffinerie de données ou le centre de traitement de données. Et c’est là que la gouvernance a lieu. Donc, vous savez, si nous nous concentrons plus ou moins sur nous, cela ressemble à cela. Vous savez, il est alimenté par des données provenant de sources internes et externes. Le concentrateur devrait, en théorie, prendre toutes les données générées. Si vous devez analyser et diffuser des données en continu, vous devez les diffuser et les gérer comme vous le feriez, puis les transmettre au concentrateur. Ou alors, tout entre dans le moyeu. Et il y a un certain nombre de choses qui se passent - ce qui se passe dans le hub. Et vous ne pouvez pas avoir une certaine quantité d’analyses et de SQL dans le hub. Mais vous avez également besoin de la virtualisation des données dans chaque cellule pour pousser les données vers d’autres zones. Mais avant que cela ne se produise, vous avez réellement besoin, d'une manière ou d'une autre, d'affiner la préparation des données. Vous pouvez appeler cela la préparation des données. C’est beaucoup plus gros que ça. Ce sont les choses que je pense que cela comprend.


En un sens, nous avons la gestion des systèmes et des services, il s’agit de la majeure partie de la couche de données. Nous devons ensuite appliquer tous les systèmes de gestion de l’effort de gestion des systèmes opérationnels que nous avons traditionnellement appliqués à la quasi-totalité des systèmes opérationnels. Mais nous devons également, d’une manière ou d’une autre, surveiller d’autres activités afin de nous assurer que ces différents niveaux de service sont atteints, car il est inévitable que des niveaux de service définis ou tout type d’analyse soient appliqués, ou que des données décisionnelles soient gérées. être actionné.


Nous avons besoin de surveillance et de gestion des performances. Si tel est le cas, nous en avons besoin pour savoir quelles ressources informatiques supplémentaires nous aurons peut-être besoin d'allouer à différents moments. Mais aussi, une grande partie de la charge de travail est en réalité assez complexe et se fait concurrence pour les ressources. Il y a quelque chose d'assez sophistiqué à faire dans ce domaine.


Nous avons maintenant un cycle de vie des données d’une manière inégalée. L’accord ici est vraiment au-dessus et au-delà de tout ce qui est, nous n’avons pas collecté de données et jeté avant. Nous avions tendance à rassembler les données dont nous avions besoin et les avons probablement conservées, puis nous les archivons. Mais une grande partie de ce que nous allons faire à partir de maintenant consiste à explorer des données. Et si vous ne voulez pas les données, enterrons-les. Ainsi, les cycles de vie des données sont différents selon la situation, mais seront également beaucoup plus agrégés de données. Par conséquent, vous savez, sachant d'où provient un agrégat… quelle est la source de l'agrégation, et ainsi de suite. C’est tout ce qui est nécessaire.


La lignée de données prête naturellement. Sans cela, vous devez connaître les problèmes, donc les données… Nous devons savoir que les données sont valides, mais avec leur fiabilité réelle.


Nous avons également la cartographie des données, car une grande partie de ces données le seront, d’une manière ou d’une autre. Et c’est, si vous voulez, cela concerne dans une certaine mesure chez MDM. C'est simplement que c'est beaucoup plus compliqué maintenant, parce que quand vous avez énormément de données définies par JSON ou basées sur notre schéma XML en lecture, vous allez avoir besoin, d'une manière ou d'une autre, d'avoir une activité très active. activité de cartographie des données en cours.


Il y a une situation de gestion de métadonnées qui dépasse le MDM, car il est nécessaire, d'une manière ou d'une autre, de créer ce que j'aimerais concevoir à présent comme une sorte d'entrepôt de métadonnées contenant tout ce qui vous intéresse. Il y a des métadonnées découverte, car certaines métadonnées de certaines données ne seront pas nécessairement déclarées et nous voulons les utiliser immédiatement. Et puis, il y a le nettoyage des données, qui est une chose énorme comme la série de choses que l’on peut faire là-bas. Et il y a aussi la sécurité des données. Toutes ces données doivent être sécurisées à un niveau acceptable, ce qui peut même signifier dans certains cas - par exemple, le cryptage de nombreuses valeurs.


Donc, toute cette charge de travail est en réalité l’empire de la gouvernance. Tout cela, d'une manière ou d'une autre, doit se dérouler au même moment ou avant, toute notre activité analytique. C'est un grand nombre d'applications coordonnées. C’est un système à part entière. Et puis, ceux qui ne le feront pas à différents moments souffriront d’une carence à mesure qu’ils avancent, car beaucoup de ces choses ne sont pas vraiment facultatives. Vous vous retrouvez avec une entropie croissante si vous ne les faites pas.


Donc, en termes d’analyse de données et de gouvernance, ce que je dirais, c’est que, en réalité, une main lave l’autre. Sans gouvernance, les analyses et la BI ne fléchiront pas dans le temps. Et sans l’analyse et la veille économique, il ne serait de toute façon pas nécessaire de gérer les données. Donc, les deux choses vont vraiment de pair. Comme on dit au Moyen-Orient, "une main lave l'autre". Et c’est tout ce que j’ai à dire. J'espère - espérons-le, nous avons maintenant récupéré Mike.


Eric: Nous faisons. Mike, je présume que tu es là. Je vais pousser votre diapositive.


Mike: Je le suis. Ok, tu m'entends?


Eric: Oui, je peux t'entendre. Vous semblez merveilleux. Alors, laissez-moi vous présenter… Voilà. Et vous êtes maintenant le présentateur. Emportez-le.


Mike: D'accord, merci! Bonjour, bon après-midi, bonsoir à vous tous. Pardonnez le hoquet au début. Pour une raison quelconque, je me suis fait taire et je pouvais voir tout le monde mais ils ne pouvaient pas m'entendre.


Bien. Donc, ce que je veux faire rapidement, c'est parler, vous savez, de l'écosystème analytique du Big Data. Si vous voulez me poser des questions, je dirai que lors de cette session ou plus tard, vous pouvez me contacter ici avec mes coordonnées. Comme je l'ai dit, au milieu de la nuit ici au Royaume-Uni.


Eh bien, laissez-moi arriver à ce que je veux parler. Clairement, au cours des dernières années, nous avons assisté à l’émergence de toutes sortes de nouveaux types de données que les entreprises veulent maintenant analyser - des données depuis le flux de clics à la compréhension des comportements en ligne, en passant par les données des médias sociaux dont Eric parlait à la début du programme ici. Je pense que Robin a mentionné JSON, BSON, XML, donc des données semi-structurées auto-descriptives. Bien sûr, nous avons aussi une tonne d’autres éléments, des données non structurées aux journaux de l’infrastructure informatique, en passant par les données des capteurs. Toutes ces sources de données relativement nouvelles auxquelles les entreprises s'intéressent maintenant, car elles contiennent des informations précieuses susceptibles d’approfondir nos connaissances.


Cela signifie donc que le paysage analytique a dépassé le cadre de l’entreposage de données traditionnel. Nous continuons de structurer les données dans le monde d'une combinaison de données structurées et multi-structurées, les données multi-structurées pouvant souvent provenir de l'intérieur ou de l'extérieur de l'entreprise. Et à la suite de ces nouveaux types de données et de ces nouveaux besoins en matière d'analyse, nous avons assisté à l'émergence de nouvelles charges de travail analytiques - de l'analyse aux données en mouvement, qui renverse en quelque sorte l'architecture de stockage de données traditionnelle. , dans les cercles traditionnels, intégrer des données, les nettoyer, les transformer, les stocker et les analyser. Mais en analysant les données en mouvement, nous les capturons, les intégrons, les préparons en les analysant puis en les stockant. Donc, les données sont analysées avant qu’elles ne soient stockées.


Nous effectuons une analyse complexe de données structurées, peut-être pour l’élaboration de modèles, ainsi que pour l’élaboration de modèles statistiques et prédictifs, ce qui n’a rien de nouveau pour certains dans un espace d’entreposage de données traditionnel. Nous avons eu une analyse exploratoire des données sur le modèle. C’est la quantité de données structurées ici. Nous avons de nouvelles charges de travail sous la forme d’analyses graphiques qui, pour mes clients des services financiers, incluent des choses comme la fraude. Cela inclut également la cybersécurité. Cela inclut les réseaux sociaux, bien sûr, la compréhension des influenceurs et des choses comme ça là-bas. Je l'ai même maitrisé en gestion, a quelques années d'analyse graphique.


L’optimisation de l’entrepôt de données ou le déchargement du traitement ETL, qui est plutôt une sorte de cas d’utilisation informatique, CIO pourrait financer cela. Et même l'archivage des données et des entrepôts de données pour le garder en ligne dans des environnements tels que Hadoop. Ainsi, toutes ces nouvelles charges de travail analytiques ont ajouté de nouvelles plates-formes, de nouvelles plates-formes de stockage, au paysage analytique. Par conséquent, au lieu d’avoir uniquement des entrepôts de données traditionnels, des dépôts de données, nous avons maintenant Hadoop. Nous disposons de bases de données NoSQL, telles que des bases de données graphiques, qui sont souvent utilisées pour des charges de travail analytiques. Bien sûr, nous pouvons maintenant analyser les graphes sur Hadoop lui-même ainsi que dans les SGBD graphes NoSQL. Robin a mentionné l'analyse en continu. Et nous avons - si vous voulez - la construction de modèles, peut-être également sur des appliances d’entrepôt de données analytiques. Mais tout cela a compliqué le paysage analytique, plusieurs plates-formes étant désormais nécessaires. Et je suppose que le défi de toute entreprise ayant un guichet ou un guichet, des finances, des achats, des ressources humaines ou un autre type d’opérations est de déterminer quels projets analytiques sont associés à une scène d’entreposage de données traditionnelle. Et une fois que vous savez que des projets analytiques sont associés à ces nouvelles plates-formes de données volumineuses et où vous voulez vous lancer, vous savez quelle charge de travail analytique vous convient, mais ne perdez pas de vue les affaires dans le sens où vous les voyez. Les projets d'analyse de données et les projets traditionnels d'entreposage de données volumineuses qui, ensemble, sont nécessaires pour renforcer leurs activités autour des clients ou des opérations, des risques, de la finance ou de la durabilité. Et par conséquent, nous souhaitons que tous ces éléments soient alignés sur nos priorités commerciales stratégiques, que nous restions sur la bonne voie pour, vous le savez, pousser les aiguilles qui doivent être insérées, vous savez, pour améliorer les performances commerciales, réduire les coûts, réduire les risques, etc., vous le savez, pour notre société dans son ensemble. Donc, ce n’est pas que l’on remplace l’autre ici par le big data et le traditionnel. Les deux sont utilisés ensemble. Et cela change radicalement l'architecture, vous savez.


Donc, ce que j’ai ici est une architecture relativement nouvelle que j’utiliserai avec mes clients. Comme vous pouvez le voir maintenant, une vaste gamme de sources de données, et pas seulement structurées, apparaît. Certains d'entre eux diffusent des données en direct, telles que des capteurs, des données de marché, ce genre de choses. Il pourrait même s'agir de données de flux de clics en direct. Il pourrait s'agir de données en streaming vidéo en direct. Il n’a donc pas besoin d’être structuré. Nous pouvons donc traiter les données par flux pour prendre des mesures automatiques en temps réel, et filtrer toutes les données d’intérêt et les transmettre à des outils de gestion des informations d’entreprise pouvant être utilisés pour alimenter des magasins de données analytiques. À moins que vous ne puissiez le voir ici, nous avons maintenant les bases de données traditionnelles Data Warehousing, Hadoop et NoSQL. Nous avons également la gestion des données de base dans le mélange. Et cela met davantage de pression sur l'ensemble de la suite d'outils de gestion de données, non seulement pour remplir ces magasins de données, mais également pour déplacer les données entre eux.


En plus de cela, nous devons simplifier les outils d'accès. Nous ne pouvons pas simplement nous tourner vers l'utilisateur et lui dire: "récupérez tous ces magasins de données, conservez ces API - votre problème." Ce que vous devez faire est de simplifier l’accès. Dans les lignes pointillées, vous constaterez que la virtualisation et l’optimisation des données masquent en quelque sorte la complexité du stockage multiple des données. Essayez de faciliter l’accès des utilisateurs finaux à cette ressource. Et bien sûr, vous avez une gamme d’outils en haut, allant des outils de BI traditionnels qui remontent du début à la fin de l’entreposage de données, puis en vous déplaçant progressivement vers la gauche de votre graphique pour vous connecter au Hadoops. puis les bases de données NoSQL du monde.


Nous avons lancé une recherche pour relancer la vie, en particulier autour du corps, de données structurées et non structurées souvent stockées dans Hadoop. Nous avons des applications analytiques personnalisées à réaliser sur une plate-forme Hadoop avec MapReduce, le framework Spark, par exemple. Nous avons des outils d’analyse graphique pour vous concentrer sur des charges de travail très spécifiques. Ainsi, une gamme d’outils et les flux de données sont également plus complexes. Ce n’est plus une rue à sens unique dans l’entrepôt de données. Ce sont maintenant des données de base, bien sûr.


Nous avons de nouvelles sources de données qui arrivent, soit capturées dans NoSQL, vous savez, des magasins de données comme MongoDB, comme Cassandra, comme HBase. Des données sont directement importées dans Hadoop pour y être analysées et préparées. Hadoop et les entrepôts de données nous apportent de nouvelles informations. Nous avons des archives provenant des entrepôts de données vers Hadoop. Nous avons maintenant accès aux flux de données vers toutes les bases de données NoSQL et les magasins de données. Donc, ce que vous pouvez voir ici, c’est qu’il ya beaucoup plus d’activités dans la gestion des données. Et cela signifie que le logiciel de gestion de données est soumis à une pression considérable. Ce n’est plus une rue à sens unique. C’est un mouvement de données à double sens. Il y a beaucoup plus d'activité en cours et, par conséquent, l'évolutivité est importante pour l'outil de gestion des données ainsi que pour la source de données.


Donc, ce tableau remonte à l'architecture que j'ai mentionnée tout à l'heure. Il vous montre les différentes charges de travail analytiques exécutées dans différentes parties de cette architecture. En bas à gauche, vous avez un flux en temps réel, un traitement de flux en cours sur des données provenant de tout type de magasin de données en direct. Nous avons effectué une analyse de classe sur des bases de données de graphes NoSQL. Cela peut aussi arriver sur Hadoop. Avec le framework Spark, par exemple, et GraphX, nous disposons d’une analyse d’investigation et de la raffinerie de données dont Robin parlait sur Hadoop. Nous avons encore des charges de travail traditionnelles et des entrepôts de données, vous savez, de puissants utilisateurs construisant des modèles statistiques et prédictifs, peut-être sur des appliances d’entrepôt de données. Et nous essayons toujours de simplifier l'accès à tout cela pour le rendre facile pour les utilisateurs finaux.


Donc, le succès dans toute cette configuration est plus que simplement analytique. Vous savez, nous pouvons mettre en place des plates-formes d’analyse, mais si nous ne pouvons pas capturer et ingérer des données à grande vitesse et à fort volume, vous savez, à l’échelle, il n’ya pas grand chose à dire. Vous savez, je n’ai rien à analyser. Et ainsi, le succès de l’analyse de données volumineuses nécessite une mise à l’échelle des systèmes opérationnels. Cela signifie que pour pouvoir prendre en charge de nouvelles transactions, vous savez, des pics. Vous savez, toutes les données non transactionnelles capturées pourraient être, vous savez, les nouveaux taux d’arrivée très, très élevés, des taux d’arrivée très élevés sur des données à grande vitesse telles que des capteurs ou toute acquisition. Nous devons être en mesure de prendre en compte tout cela - de pouvoir capturer ce type de données et de les amener pour analyse. Nous devons également mettre à l'échelle l'analyse elle-même, simplifier l'accès aux données que j'ai déjà mentionnées. Et puis, attachez ça. Vous savez, nous devons être en mesure de redéfinir ces systèmes opérationnels pour lui donner une boucle fermée.


Ainsi, vous savez, le fait de redimensionner le côté opérationnel de la maison pour capturer des données s'inscrit dans l'univers de la base de données NoSQL. Je veux dire, vous voyez ici cinq catégories de base de données NoSQL. Cette catégorie sera modélisée simplement comme une combinaison des quatre autres ci-dessus. En général, vous connaissez ses valeurs de clé, ses documents stockés et ses bases de données de familles de colonnes - les trois premiers qui y figurent - qui sont en quelque sorte utilisés pour les types les plus divers de données transactionnelles et non transactionnelles.


Certaines de ces bases de données supportant en tant que propriétés; certains non. Néanmoins, vous savez, nous assistons à l’introduction de ces solutions pour adapter ce type d’applications. Ainsi, par exemple, nous nous sommes éloignés des seuls employés qui effectuent des transactions au clavier pour maintenant les clients et les masses utilisant de nouveaux appareils pour pouvoir le faire. Nous avons assisté à une augmentation considérable du nombre de transactions effectuées dans les entreprises. Nous devons donc adapter les applications transactionnelles à cette fin.


De manière générale, cela peut être fait sur les bases de données NewSQL en tant que base de données relationnelle telle que NuoDB et VoltDB illustrées ici. Certaines bases de données NoSQL pouvant éventuellement prendre en charge des propriétés ACID garantissant le traitement des transactions peuvent être en jeu. Ceci s'applique également aux données non transactionnelles telles que les données du panier avant une transaction, vous savez, avant que les gens achètent des choses, les données de capteur, vous savez, car je perds une lecture de capteur parmi des centaines de millions de lectures de capteur. Ce n'est pas grand chose. Clics, vous savez, dans le monde des clics - si j'utilise un clic, ce n'est pas grave.Donc, vous savez, nous n’avons pas nécessairement besoin des propriétés ACID, c’est souvent là que les bases de données NoSQL entrent en jeu, c’est là: cette capacité à effectuer un traitement très élevé et à la bonne taille pour capturer ces nouveaux types de données.


Dans le même temps, nous voulons que l’analyse évolue. Ainsi, extraire les données des magasins de données vers les plates-formes analytiques ne va plus les pirater, car les données sont trop volumineuses. Ce que nous souhaitons réellement, c’est d’introduire les analyses dans l’entrepôt de données de l’entreprise, puis dans Hadoop, dans le traitement du flux afin de pouvoir les analyser dans les données. Cependant, ce n’est pas parce que l’on dit qu’il s’agit d’analyses de base de données ou d’analyse Hadoop que l’analyse s'exécute en parallèle. Et franchement, si vous envisagez d’investir dans ces nouvelles technologies évolutives massivement parallèles telles que Hadoop, telles que les appliances d’entrepôt de données et autres, comme les moteurs de traitement de flux en cluster, vous avez besoin de l’analyse parallèle.


Donc, ce n’est que le départ. Vous savez, si nous disposons d’analyses permettant de prévoir les événements pour les clients, les opérations, les risques, etc., nous voulons qu’ils s’exécutent en parallèle, et pas uniquement sur la plate-forme. Nous voulons les deux. Et c’est parce que, vous le savez, la technologie ressemble également à ces nouveaux outils de découverte visuelle tels que SAS. C’est en fait l’un de nos sponsors ici.


Les utilisateurs souhaitent au moins exploiter ceux de Hadoop, puis de l’analyse de bases de données. Et nous voulons que ceux-ci fonctionnent en parallèle afin de pouvoir offrir les performances nécessaires sur des volumes de données aussi importants. En même temps, nous essayons de simplifier l’accès à tout cela. Et oui, SQL est maintenant de nouveau à l'ordre du jour. Vous savez, SQL est - SQL sur Hadoop est chaud en ce moment. Je suis en train de le suivre dans 19 initiatives SQL et Hadoop actuellement. De plus, vous pouvez voir que nous pouvons obtenir ces données, vous le savez, de différentes manières, de sorte que, pour accéder directement à SQL sur Hadoop même, nous pouvons accéder à un index de recherche SQL. Ainsi, comme vous le savez, certains des éditeurs de recherche de cet espace peuvent avoir un accès SQL à des bases de données relationnelles analytiques contenant des tableaux Excel à Hadoop.


Nous pouvons maintenant avoir un accès SQL à un serveur de virtualisation de données qui peut ensuite être connecté à un entrepôt de données sur Hadoop. Je commence même maintenant à voir émerger un accès SQL aux données en streaming en direct. Ainsi, l'accès SQL à tout cela augmente rapidement. Et une partie du défi réside simplement parce que l’accès SQL est commercialisé sur le marché. La question est de savoir si SQL peut traiter des données complexes. Et ce n’est pas nécessairement simple. Il y a toutes sortes de complications ici, y compris le fait que les données JSON puissent être imbriquées. Nous pouvons avoir des enregistrements de variantes de schéma. Ainsi, le premier enregistrement a un schéma. Le deuxième enregistrement a un schéma différent. Ces choses sont très différentes de ce qui se passe dans un monde relationnel.


Nous devons donc nous interroger sur le type de données que nous essayons d’analyser et sur le type de caractéristiques analytiques. Est-ce, vous savez, le groupe que vous voulez faire? Est-ce l'apprentissage machine? Est-ce l'analyse graphique? Pouvez-vous le faire à partir de SQL? Vous savez, est-ce invocable depuis SQL? Combien d'utilisateurs simultanés avons-nous le faire? Vous savez, nous avons des centaines d’utilisateurs simultanés. Est-ce possible avec des données complexes? Vous savez, toutes ces choses sont des questions clés. Donc, j'ai en quelque sorte fait une liste de quelques-uns ici que je pense que vous devriez considérer. Vous savez, quel genre de formats de fichiers? De quel type de données parle-t-on? Quel type de fonctions analytiques pouvons-nous appeler à partir de SQL pour obtenir des données complexes? Et les fonctions fonctionnent en parallèle. Je veux dire, ils doivent courir en parallèle si nous devons être en mesure de faire évoluer cela. Et puis-je associer des données dans Hadoop au-delà de ce jour, vous savez, ou ce n’est pas faisable? Et que vais-je faire de tous ces types de charges de travail de requête?


Et comme nous le verrons, vous savez, de ce que j’ai vu, il y a beaucoup de différences entre les distributions SQL et Hadoop. Ce sont tous ceux que je suis en train de suivre. Et au fait, c'est du SQL pur sur Hadoop. Cela n'inclut même pas la virtualisation des données à ce stade. Et donc, il y a beaucoup de choses en place et beaucoup de possibilités de consolidation, ce qui, je pense, se produira au cours de la prochaine année, environ dix-huit mois. Mais cela ouvre également une autre chose, à savoir que je peux avoir potentiellement plusieurs moteurs SQL sur les mêmes données dans Hadoop. Et c’est quelque chose que vous ne pouvez pas faire en relationnel.


Bien sûr, cela signifie que vous devez alors savoir, vous savez, quel type de charge de travail de requête est-ce que je cours? Devrais-je exécuter cela en batch sur une initiative SQL sur Hadoop particulière? Devrais-je exécuter des charges de travail de requête interactives via une autre initiative SQL sur Hadoop, etc., afin de savoir à laquelle me connecter? Idéalement, nous ne devrions pas faire cela. Nous devrions simplement avoir, vous savez, posé une question à ce sujet. Vous savez, certains optimiseurs déterminent la meilleure façon de le faire. Mais nous n’en sommes pas encore là, à mon avis.


Néanmoins, la virtualisation des données, comme je l’ai mentionné précédemment, joue un rôle très important dans la simplification de l’accès à plusieurs magasins de données. Et si nous créons de nouvelles informations sur Hadoop, il est certainement plausible pour nous d'associer ces data-to-data et ces entrepôts de données traditionnels via la virtualisation des données, par exemple, sans nécessairement transférer les données de Hadoop vers des entrepôts de données traditionnels. Bien sûr, vous pouvez le faire aussi. Il est également plausible d’archiver des données d’entrepôts de données traditionnels dans Hadoop. Je peux toujours y arriver et le relier à ce qui se trouve dans notre entrepôt de données pour la virtualisation des données. Donc, pour moi, je pense que la virtualisation des données a un grand avenir dans cette architecture globale et simplifie l’accès à tous ces magasins de données.


Et n'oubliez pas que lorsque nous créons ces nouvelles informations, qu'il s'agisse de systèmes relationnels ou NoSQL, nous souhaitons toujours les réintégrer dans nos opérations, afin de pouvoir maximiser la valeur de ce que nous avons trouvé, de manière à pouvoir nous en servirons pour prendre des décisions plus efficaces et plus rapides dans cet environnement afin d’optimiser notre entreprise.


Donc, pour conclure, ce que je vois, c’est que nous avons besoin de nouvelles sources de données. Nous avons de nouvelles plateformes sur une architecture plus compliquée, si vous voulez, pour gérer ça. Et Hadoop devient très, très important, suffisant pour la préparation des données pour nos bacs à sable liquides, pour la recherche d'archives, l'archivage depuis un entrepôt de données, la gestion des données déployée pour aller au-delà de l'entreposage de données dans la gestion des données sur toutes ces plates-formes et pour la création de nouveaux outils. capable d'analyser et d'accéder aux données dans ces environnements, de disposer de technologies évolutives pour une meilleure ingestion des données et de redimensionner l'analyse en les déplaçant vers les plates-formes pour les rendre plus parallèles. Et ensuite, espérons-le, pour simplifier l'accès à tout cela grâce au SQL émergent qui arrive par le haut. Cela vous donne donc une idée de la direction que nous prenons. Alors, avec ça, je reviens à, je suppose, Eric maintenant, si?


Eric: Ok, c’est fantastique. Et les gens, je dois dire, entre ce que Robin et Mike viennent de dire, c’est probablement aussi exhaustif et concis dans la vue d’ensemble du paysage que vous allez trouver où que vous soyez. Laissez-moi aller de l'avant et faire la queue en premier sur George Corugedo. Et voilà. Permettez-moi de prendre ceci pour une seconde rapide. Très bien, George, je suis sur le point de te remettre les clés et de les emporter. La parole est à vous.


George: Génial! Merci beaucoup, Eric, et merci, Rob et Mike. C'était une excellente information et beaucoup de choses sur lesquelles nous sommes d'accord. Donc, revenons à la discussion de Robin, parce que, vous savez, ce n’est pas une coïncidence si RedPoint est là et SAS est ici. Parce que RedPoint, nous nous concentrons vraiment sur les données, sur la gouvernance, sur le traitement des données et sur la préparation à une utilisation en analytique. Alors permettez-moi de passer en revue ces deux diapositives. Et vraiment, discutez et reprenez le point de Robin sur le MDM, son importance et son utilité, et je pense - et nous pensons - que Hadoop peut être dans le monde du MDM et de la qualité des données.


Vous savez, Robin parlait un peu, vous savez, comment cela est lié au monde des entrepôts de données d'entreprise et je viens - vous savez, j'ai passé plusieurs années chez Accenture. Et ce qui était intéressant, c’est combien de fois nous avons dû faire affaire avec des entreprises et essayer de comprendre ce qu’il fallait faire avec l’entrepôt de données qui avait été en fait abandonné. Cela est dû en grande partie au fait que l'équipe de l'entrepôt de données n'a pas vraiment aligné sa construction sur les utilisateurs professionnels ou les consommateurs de données. Ou bien, cela a pris tellement de temps que, au moment où ils ont construit la chose, son utilisation ou sa raison d’être ont évolué.


Et l’une des choses qui, à mon avis, est, et qui me passionne tellement, est l’idée d’utiliser Hadoop pour la gestion des données de base, pour la qualité des données et pour la préparation des données, c’est que vous pouvez toujours revenir aux données atomiques dans une Le lac de données Hadoop ou le réservoir de données, ou le référentiel de données, ou le hub, ou le type de buzz que vous souhaitez utiliser. Mais comme vous conservez toujours ces données atomiques, vous avez toujours la possibilité de vous réaligner avec les utilisateurs professionnels. En tant qu'analyste - car j'ai commencé ma carrière de statisticien -, vous savez, rien n'est pire que, vous savez, les entrepôts de données d'entreprise sont parfaits pour générer des rapports, mais si vous souhaitez réellement effectuer une analyse prédictive, ils vraiment pas utile, car ce que vous voulez vraiment, ce sont les données comportementales granulaires qui ont été en quelque sorte résumées et agrégées dans l’entrepôt de données. Donc, je pense que c'est vraiment une fonctionnalité importante, et c'est une chose sur laquelle je pense que je pourrais être en désaccord avec Robin, c'est que personnellement, je laisserais des données dans le Data Lake ou dans le hub de données aussi longtemps que possible, parce que les données sont là et c'est propre, vous pouvez les regarder d'une direction, d'une autre. Vous pouvez le fusionner avec d'autres données. Vous avez toujours la possibilité de revenir sur cette question et de la restructurer, puis de vous réaligner avec une unité opérationnelle et les besoins que cette unité pourrait avoir.


L’un des autres aspects intéressants de cette question est qu’étant donné qu’il s’agit d’une plate-forme informatique aussi puissante que possible, nous avons constaté qu’une grande partie de la charge de travail dont nous parlons l’a amenée dans Hadoop. Et tandis que, je pense, Mike parlait de toutes les technologies différentes qui existent dans le monde de - dans ce type d'écosystème de données volumineuses, nous pensons que Hadoop est vraiment le cheval de bataille pour faire de cette grande échelle un traitement intensif en calcul qui données de base et qualité des données requises. Parce que si vous pouvez le faire là-bas, vous savez, la seule économie qui consiste à transférer des données de vos bases de données coûteuses vers des bases de données économiques, est en train de motiver une telle prise en main actuellement dans les grandes entreprises.


Maintenant, bien sûr, il y a des défis, non? Il y a des défis autour des technologies. Beaucoup d'entre eux sont très immatures. Je dirais, vous savez, je ne sais pas combien, mais certaines des technologies mentionnées par Mike sont toujours en version zéro point, quelque chose, non? Donc, ces technologies sont très jeunes, très immatures, toujours basées sur du code. Et cela crée vraiment un défi pour les entreprises. Et nous nous concentrons vraiment sur la résolution de problèmes au niveau de l'entreprise. Nous pensons donc qu’il doit exister une méthode différente, et c’est ce que nous proposons, une façon différente de traiter certaines choses en utilisant certaines de ces technologies très naissantes.


Et puis, et puis l'autre question intéressante ici, qui a été mentionnée précédemment, qui est, lorsque vous avez des données que vous capturez dans un environnement Hadoop de tout type, vous savez, il s'agit généralement d'un schéma en lecture plutôt que d'un schéma en écriture à quelques exceptions près. Et cette lecture, beaucoup de choses sont faites par des statisticiens. Les statisticiens doivent donc disposer d’outils leur permettant de structurer correctement les données à des fins d’analyse, car au bout du compte, pour rendre les données utiles, elles doivent être structurées de manière à pouvoir en voir ou à répondre à une question ou à une question. une entreprise, un certain type d’entreprise, crée de la valeur commerciale.


Donc, là où nous intervenons, c’est que nous avons une clé principale et une application de gestion EPL, ELT très qualitatives pour la qualité des données des ELT. Il est sur le marché depuis de très nombreuses années. Et il a toutes les fonctionnalités ou une grande partie des fonctionnalités énumérées par Robin dans ce graphique circulaire - de la capture de données brutes pures dans une grande variété de formats et de structures XML et autres, à la possibilité d'effectuer tout le nettoyage, la l'achèvement des données, la correction des données, les bits de base géospatiaux des données. C’est quelque chose qui devient de plus en plus important de nos jours avec l’Internet des objets. Vous savez, la géographie est associée à une grande partie de ce que nous faisons ou à une grande partie de ces données. Et ainsi, tout l’analyse, la tokenisation, le nettoyage, la correction, le formatage, la structuration, etc., tout est fait dans notre plate-forme.


Et puis, et peut-être, nous pensons que l'idée de déduplication est la plus importante. Vous savez qu'au fond, si vous examinez une définition de la gestion des données de base, la déduplication est au cœur de celle-ci. Il est en mesure d’identifier des entités à partir de différentes sources de données, puis de créer une fiche pour cette entité. Et cette entité pourrait être une personne. L'entité pourrait être une partie d'un avion, par exemple. L’entité peut être un aliment comme nous l’avons fait pour l’un de nos clients du club de santé. Nous avons créé une base de données maîtresse pour eux. Ainsi, quelles que soient les entités avec lesquelles nous travaillons - et bien sûr, de plus en plus, il existe des personnes et des mandataires pour leur identité qui sont des choses comme des pseudonymes ou des comptes sociaux, tous les dispositifs associés aux gens, des choses comme les voitures et les voitures. téléphones, et tout ce que vous pourriez imaginer.


Vous savez, nous travaillons avec un client qui installe toutes sortes de capteurs dans les vêtements de sport. Les données proviennent donc de toutes les directions. Et d’une manière ou d’une autre, c’est une réflexion ou une représentation de l’entité centrale. Et de plus en plus, il s’agit de personnes et de la capacité à identifier les relations entre toutes ces sources de données et leur lien avec cette entité centrale, puis à pouvoir suivre cette entité centrale au fil du temps afin que vous puissiez analyser et comprendre les changements entre ces entités. et tous les autres éléments qui figurent dans cette représentation de cette entité, un élément vraiment essentiel pour l'analyse longitudinale et à long terme des personnes, par exemple. Et c’est vraiment l’un des avantages vraiment importants que, je pense, le big data peut nous apporter, c’est une bien meilleure compréhension des personnes, et à long terme, ainsi que de la confusion et du comportement des gens quand ils se comportent avec quels appareils, etc. .


Alors, laissez-moi passer rapidement ici. Eric a mentionné YARN. Vous savez, je vais en parler brièvement, parce que pendant que YARN - les gens parlent de YARN. Je pense qu’il ya encore beaucoup d’ignorance à propos de YARN. Et pas beaucoup de gens vraiment - il y a encore beaucoup de malentendus à propos de YARN. Et le fait est que si votre application a été architecturée correctement et que vous disposez du niveau ou de la parallélisation appropriés dans votre architecture, vous pouvez tirer parti de YARN pour utiliser Hadoop comme plate-forme de mise à l'échelle. Et c’est exactement ce que nous avons fait.


Vous savez, encore une fois, juste pour souligner certaines des définitions autour de YARN. Pour nous, ce qu’est vraiment YARN nous a permis, à nous-même et à d’autres organisations, de devenir des pairs de MapReduce et de Spark, ainsi que de tous les autres outils existants. Mais le fait est que nos applications génèrent du code optimisé directement dans YARN dans Hadoop. Et il ya un commentaire très intéressant que Mike a mentionné, parce que, vous savez, la question de l’analyse et de notre analyse, juste parce qu’elles font partie du cluster, fonctionnent-elles vraiment en parallèle? Vous pouvez poser la même question à propos de nombreux outils de qualité des données existants.


La plupart du temps, les outils de qualité existants doivent soit extraire les données, soit insérer du code. Et dans de nombreux cas, il s’agit d’un seul flux de données qui est traité à cause de la façon dont vous devez le faire. comparer des enregistrements, parfois dans des activités de type qualité. Et le fait est que, grâce à YARN, nous avons vraiment pu tirer parti de la parallélisation.


Et juste pour vous donner un aperçu rapide, car un autre commentaire est fait sur l'importance de pouvoir étendre les bases de données traditionnelles, les nouvelles bases de données, etc., que nous implémentons ou que nous installons en dehors du cluster. Et nous envoyons nos fichiers binaires directement dans le gestionnaire de ressources, YARN. Et cela, puis YARN le distribue entre les nœuds du cluster. Et ce que cela fait, c’est que YARN - nous permettons à YARN de gérer et d’effectuer son travail, qui consiste à déterminer où se trouvent les données et à transférer le travail aux données, le code aux données et non à les déplacer. Lorsque vous entendez parler des outils de qualité des données et que ceux-ci vous indiquent que la meilleure pratique consiste à déplacer les données hors de Hadoop pour les sauver, car elles ne sont pas comme ça. Vous voulez prendre le travail aux données. Et c’est ce que YARN fait en premier. Il achemine nos fichiers binaires vers les nœuds où se trouvent les données.


Et également parce que nous sommes en dehors du cluster, nous pouvons également accéder à toutes les bases de données traditionnelles et relationnelles afin que nous puissions avoir des travaux 100% client / serveur sur une base de données traditionnelle, 100% Hadoop ou des travaux hybrides passant par le serveur client Hadoop. , Oracle, Teradata - tout ce que vous voulez et tous dans le même travail, car cette implémentation unique peut accéder aux deux côtés du monde.


Et puis, pour revenir à l’idée de la nascence des outils, vous voyez ici, c’est une simple représentation. Et nous essayons de simplifier le monde. Et nous le faisons en apportant un très large éventail de fonctionnalités autour de HDFS pour le rendre… Et ce n’est pas parce que nous essayons d’éliminer toutes les technologies innovantes qui existent. Les entreprises ont juste besoin de stabilité et n’aiment pas les solutions basées sur du code. Nous essayons donc de donner aux entreprises un environnement d’application familier, reproductible et cohérent qui leur permette de créer et de traiter des données de manière très prévisible.


Rapidement, c’est le genre d’impact que nous obtenons avec notre application. Vous voyez MapReduce vs Pig vs RedPoint - aucune ligne de code dans RedPoint. Six heures de développement à MapReduce, trois heures de développement chez Pig et 15 minutes de développement à RedPoint. Et c’est là que nous avons vraiment un impact énorme. Le temps de traitement est également plus rapide, mais le temps passé par les gens, leur temps de productivité, est considérablement augmenté.


Et ma dernière diapositive ici, je veux revenir à cette idée, car il s’agit de notre position sur l’utilisation d’un lac de données, d’un hub de données ou d’une raffinerie de données comme point central d’ingestion. Impossible d’être plus d’accord avec cette idée. Et nous sommes actuellement en discussion avec de nombreux responsables des données des grandes banques mondiales. C’est l’architecture de choix.L'ingestion de données à partir de toutes les sources effectue le traitement de la qualité des données et la gestion des données principales à l'intérieur du lac de données, puis transfère les données là où elles doivent aller pour prendre en charge les applications, pour prendre en charge la BI, peu importe la situation. Et puis, si vous avez des analyses dans la BI, elles peuvent s’exécuter directement dans le lac de données, là où cela est préférable, cela peut commencer tout de suite. Mais très d'accord avec cette idée. Cette topologie en est une qui gagne beaucoup d’attrait sur le marché. Et c'est tout.


Eric: D'accord, bien. Avançons ici. Je vais donner la parole à Keith. Et Keith, vous avez environ 10, 12 minutes pour faire bouger la maison ici. Nous avons pris le temps d'aller un peu longtemps dans ces spectacles. Et nous avons annoncé 70 minutes pour celui-ci. Alors, allez-y, cliquez n'importe où sur la diapositive et utilisez la flèche vers le bas pour l'enlever.


Keith: Bien sûr. Pas de problème, Eric. Je vous en suis reconnaissant. Je vais aborder quelques points à propos de SAS, puis je vais passer à l’architecture technologique de l’interaction entre SAS et le monde du Big Data. Il y a beaucoup à expliquer dans tout ça. Nous pourrions passer des heures à le parcourir de manière très détaillée, mais en dix minutes, vous devriez être en mesure de comprendre brièvement où SAS a introduit les technologies d'analyse, de gestion des données et de veille stratégique dans ce monde du Big Data.


Tout d’abord, parlons un peu de SAS. Si vous n’êtes pas familier avec cette organisation, cela fait 38 ans que nous faisons de l’analyse avancée, de l’intelligence d’affaires et de la gestion de données, non seulement à base de données volumineuses, mais à faible encombrement. Nous avons une énorme clientèle existante, environ 75 000 sites à travers le monde, travaillant avec certaines des plus grandes organisations du marché. Nous sommes une organisation privée avec environ 13 000 employés et des revenus de 3 milliards de dollars. Et je suppose que l’important, c’est que nous avons traditionnellement réinvesti des quantités importantes de nos revenus dans notre organisation de R & D, ce qui vous a réellement permis de supporter bon nombre de ces technologies et plateformes incroyables. allez voir aujourd'hui.


Donc, je vais passer directement à ces diagrammes d’architecture vraiment effrayants. Nous allons travailler de gauche à droite dans mes diapositives. Donc, il y a des choses familières que vous allez voir à l'intérieur de cette plate-forme. À gauche, toutes les sources de données que nous parlons d’intégrer dans ces plates-formes Big Data. Et puis, vous avez cette plate-forme Big Data.


Je n’ai pas simplement placé le mot Hadoop au sommet, car au final, les exemples que je vais donner aujourd’hui concernent spécifiquement toutes les technologies où nous nous croisons avec ces plates-formes Big Data. Il se trouve que Hadoop est l’une des solutions les plus robustes en matière de déploiement, mais nous en croisons aussi assez et avons développé bon nombre de ces technologies depuis un certain temps avec certains de nos autres partenaires d’entrepôts de données d’entreprise tels que Teradata. Oracle, Pivotal et similaires. Je ne peux donc pas entrer dans les détails car toutes les technologies différentes sont prises en charge sur quelle plate-forme, mais soyez assurés que toutes celles que je décris aujourd’hui sont pour la plupart tout ce que Hadoop recoupe et une grande quantité d’entre elles recoupe d’autres partenaires technologiques qui on a. Nous avons donc cette grande plate-forme assise là.


Le prochain à droite, nous avons notre serveur d'analyse SAS LASR. Or, il s’agit essentiellement d’un serveur d’applications analytiques en mémoire, extrêmement parallèle. Soyons clairs, ce n’est pas une base de données en mémoire. C’est vraiment conçu à partir de la base. Il ne s’agit pas d’un moteur de recherche, mais est conçu pour traiter des demandes analytiques à grande échelle d’une manière extrêmement parallèle. C’est donc les applications de clé de service que vous voyez à droite.


Nous allons entrer un peu plus dans, vous savez, comment les gens déploient ces choses. Mais essentiellement, l’application - voyez-vous là-bas - la première est notre analyse SAS hautes performances. Cela va être - j'utilise beaucoup de nos technologies et plates-formes existantes comme Enterprise Miner ou juste un SAS, et pas seulement en multithreading avec certains de ces algorithmes que nous avons intégrés à ces outils que nous avons conçus pour années, mais aussi à massivement parallèle. Donc, pour déplacer les données de cette plate-forme big data dans l'espace mémoire vers ce serveur d'analyse LASR, afin que nous puissions exécuter des algorithmes analytiques - vous savez, bon nombre des nouveaux outils d'apprentissage automatique, réseaux neuronaux, régressions aléatoires de forêt, etc. choses - encore une fois, les données conservées en mémoire. Par conséquent, éliminer le goulet d’étranglement de certains paradigmes de MapReduce, qui nous aligne sur ces plates-formes, n’est pas la façon dont vous souhaitez effectuer un travail analytique. Nous voulons donc pouvoir faire remonter les données une fois dans la mémoire et les parcourir plusieurs fois, vous savez. C’est donc l’idée d’utiliser ce serveur analytique LASR hautes performances.


Nous avons également - les autres applications en dessous, l'analyse visuelle, qui nous permet de conserver ces données en mémoire et de servir une population plus importante sur les mêmes données. Donc, permettre aux gens de faire de l’exploration de données volumineuses. Ainsi, avant de commencer nos travaux de développement de modèle, nous explorons des données, nous les comprenons, nous établissons des corrélations, établissons des tendances ou établissons des arbres de décision - ce genre de choses - mais de manière très visuelle et interactive sur des données conservées en mémoire. Plate-forme. Cela concerne également notre communauté de BI en ce qu’il dispose d’une base très large d’utilisateurs pouvant utiliser cette plate-forme pour réaliser des types d’enregistrements standard que vous voyez - ce qui est quasiment tout, vous savez, le fournisseur de BI.


La prochaine étape, nous passons ensuite en service. Et pour aider nos statisticiens et nos analystes à être en mesure de faire ce type de modélisation ad hoc avec des données conservées en mémoire, supprimées de l'analyse visuelle et explorées dans notre application de statistiques visuelles. Il s’agit d’une opportunité pour les personnes de saisir, de ne pas exécuter de statistiques sur des lots qui parcouraient auparavant les types, d’exécuter des modèles, de voir les résultats. Donc, cela peut exécuter le modèle, voir les résultats. Ceci consiste à glisser-déposer visuellement dans la modélisation statistique interactive. Ainsi, cela aide nos statisticiens et nos experts en données à effectuer une grande partie de ces premiers travaux de statistiques visuelles exploratoires.


Et puis, nous n’avons pas oublié nos codeurs: ceux qui veulent vraiment avoir la possibilité de peler les couches d’interface ci-contre, c’est écrire des applications et écrire leur propre code base en SAS. Et ce sont nos statistiques en mémoire pour Hadoop. Et c’est essentiellement la couche de code qui nous a permis d’interagir avec ce serveur Analytic LASR afin d’émettre des commandes directement et de personnaliser ces applications en fonction de notre demande. C’est la pièce analytique.


Comment ces choses se préparent… Oups, je suis désolé les gars. Nous y voilà.


Nous avons donc plusieurs façons de procéder. L'une consiste à le faire avec le Big Data - dans ce cas, avec Hadoop. Et c’est là que SAS LASR Analytic Server s’exécute dans un cluster séparé de machines optimisées pour l’analyse intensive. Ceci est niché à proximité de la plate-forme Big Data, ce qui nous permet de l'adapter séparément à la plate-forme Big Data. Nous voyons donc des gens faire cela quand ils ne veulent pas que ce que je caractérise soit un logiciel de vampire qui ronge chacun des nœuds de leur cluster Hadoop. Et ils ne font pas nécessairement évoluer cette plate-forme de données volumineuses appropriée pour effectuer des analyses en mémoire lourdes. Ainsi, vous pouvez avoir 120 nœuds de leur cluster Hadoop, mais ils peuvent également avoir 16 nœuds de serveurs d'analyse conçus pour effectuer ce type de travail.


Nous sommes toujours autorisés à maintenir ce parallélisme à partir de la plate-forme Big Data pour extraire les données en mémoire. Il s’agit donc vraiment d’une utilisation de SAS avec la plate-forme Hadoop. Un modèle de rendez-vous différent consiste à dire, eh bien, nous pouvons également utiliser cette plateforme de produits de base et le promouvoir - essentiellement, exécuter le serveur Analytic LASR sur les plateformes Hadoop. C’est donc là que nous sommes… vous opérez au sein de la plate-forme Big Data. C’est aussi certains de nos autres fournisseurs d’appliques. Cela nous a donc permis d’utiliser essentiellement cette plate-forme de produits de base pour effectuer ce travail.


Nous le constatons plus souvent avec des analyses telles que les analyses hautes performances, qui consistent en une analyse analytique à usage unique ou à usage unique, plus orientée vers le traitement par lots, car vous ne voulez pas nécessairement utiliser l'espace mémoire de Hadoop. Plate-forme. Nous sommes très flexibles avec ce type de modèle de déploiement, et nous travaillons certainement avec YARN dans beaucoup de cas pour nous assurer que nous jouons de belles grappes.


Très bien, c’est le monde analytique, il suffit d’être clair avec l’application analytique. Mais j’ai mentionné que SAS, au tout début, est également une plate-forme de gestion de données. Et il y a des choses qui conviennent pour insérer de la logique dans cette plateforme, le cas échéant. Donc, il y a plusieurs façons de le faire. L’un d’entre eux est celui de l’intégration de données: effectuer un travail de transformation de données sur des données n’a peut-être pas la moindre intention de le retirer comme nous l’avons déjà entendu, en exécutant des routines de qualité des données qui sont très volumineuses. Nous voulons absolument intégrer des éléments tels que les routines de qualité des données dans cette plate-forme. Et puis, des choses comme la notation de modèles. J'ai donc développé mon modèle. Je ne veux pas réécrire cette chose dans MapReduce et rendre difficile et fastidieux pour moi de refaire ce travail dans la plateforme de base de données native.


Ainsi, si vous regardez, par exemple, notre accélérateur de scores pour Hadoop, cela nous permet essentiellement de prendre un modèle et d’enfoncer la logique mathématique SAS dans cette plate-forme Hadoop et de l’exécuter là-bas, en utilisant le parallélisme à l’intérieur de cette plate-forme Big Data. Nous avons ensuite notre accélérateur de code pour diverses plates-formes, y compris Hadoop, ce qui nous permet essentiellement d’exécuter du code de pas de données SAS à l’intérieur de la plate-forme de manière massivement parallèle, ce qui permet d’effectuer des types de transformation des données sur la plate-forme. Et puis notre accélérateur de qualité de données SAS qui nous permet d’avoir une base de connaissances de qualité qui peut faire des choses comme l’appariement des sexes, le code de correspondance de normalisation - toutes les différentes choses que vous avez déjà entendues au sujet de la qualité des données.


Et puis, dernier élément, il y a Data Loader. Nous savons que nos utilisateurs métier devront être en mesure de ne pas avoir à écrire du code, mais à effectuer un travail de transformation des données sur ces plateformes Big Data. Data Loader est une belle interface graphique WYSIWYG qui nous permet de combiner ces autres technologies. Par exemple, exécuter une requête Hive ou une routine de qualité des données sans avoir à écrire de code dans ce cas est comme un assistant virtuel.


La dernière chose que je mentionnerai est cet avant-corps. Comme je l'ai déjà mentionné, nous avons un énorme pied SAS dans le monde. Et cela, nous ne pouvons pas nécessairement faire en sorte que toutes les plates-formes existantes soient présentes immédiatement dans cet espace. Nous avons donc certainement un groupe d'utilisateurs qui doivent disposer de données sur ces plateformes Big Data, telles que l'extraction de données de Teradata et leur restitution dans Hadoop, et inversement. Exécution des modèles Je sais déjà comment exécuter sur mes serveurs SAS, mais je dois obtenir des données qui sont maintenant placées sur la plate-forme Hadoop. Il existe donc une autre petite icône appelée «de», qui nous permet de nous connecter à l’aide de nos moteurs d’accès SAS - moteurs d’accès de Hadoop à Cloudera dans Pola, à Teradata, à Greenplum, etc. La liste s’allonge. Cela nous permet d'utiliser nos plates-formes SAS matures existantes, déjà en place, pour extraire des données de ces plates-formes, effectuer le travail que nous avons besoin d'effectuer et repousser les résultats dans ces domaines.


La dernière chose que je vais mentionner est que toutes ces technologies que vous voyez sont toutes régies par les mêmes métadonnées communes standard. Nous parlons donc de la transformation du travail, de la règle de qualité des données à l'œuvre, de son déplacement en mémoire pour pouvoir effectuer des analyses, du développement de modèles lors du scoring. Nous avons là tout le style de vie analytique, le cycle de vie étant régi par des métadonnées communes, par la gouvernance, par la sécurité, par toutes les choses dont nous avons parlé plus tôt aujourd’hui.


Donc, juste une récapitulation, il y a vraiment ces trois grandes choses à emporter là-bas. Premièrement, nous pouvons traiter la plate-forme de données comme n'importe quelle autre source de données, en tirant dessus, en leur envoyant la pression quand cela est approprié et pratique. Nous pouvons travailler avec ces plates-formes Big Data, en répertoriant les données dans une plate-forme analytique avancée spécialement conçue pour la mémoire. Donc, c’est le serveur LASR.


Enfin, nous pouvons enfin travailler directement sur ces plateformes Big Data, en exploitant leurs capacités de traitement distributif sans déplacer les données.


Eric: C'est fantastique, les gars. Ouais, c'est génial! Alors, passons directement à certaines questions. Nous allons généralement environ 70 minutes ou un peu plus longtemps sur ces événements. Donc, je vois que nous avons toujours un bon public assis là-bas. George, je pense que je vais vous poser notre première question. Si vous parlez d'insérer votre son binaire dans Hadoop, je pense que vous avez vraiment optimisé le flux de travail informatique. Et c’est toute la clé pour pouvoir réaliser ce type de gouvernance en temps réel et de style de qualité des données, car c’est la valeur que vous souhaitez obtenir, non? Si vous ne voulez pas retourner dans le vieux monde du MDM, il est très lourd et prend beaucoup de temps, et vous devez vraiment forcer les gens à agir de certaines manières, ce qui ne fonctionne presque jamais. Et donc, ce que vous avez fait est que vous avez condensé le cycle de ce qui était. Appelons cela des jours, des semaines, parfois même des mois en secondes, non? Est-ce ce qui se passe?


George: C’est tout à fait vrai, car l’échelle que nous obtenons et les performances que nous obtenons d’une grappe sont vraiment ahurissantes en termes de, simplement, vous savez, j’ai toujours un peu peur des repères. Mais pour l’ordre de grandeur, lorsque nous exécutons un milliard, 1,2 milliard d’enregistrements et procédons à une standardisation complète de l’adresse (je dis machine HP moyenne gamme), il faudrait, comme, vous savez, huit machines à processeur, vous savez , 2 Go de RAM par cœur, cela prendrait 20 heures. Nous pouvons le faire en huit minutes environ sur un cluster de 12 nœuds. Et donc, l’ampleur du traitement que nous pouvons faire à présent est tellement différente que cela va très bien avec l’idée que vous avez toutes ces données à votre disposition. Donc, le traitement n’est pas aussi risqué. Si vous l'avez mal fait, vous pouvez le refaire. Vous avez le temps, vous savez. Cela a vraiment changé l'ampleur de cette situation où, vous savez, ce type de risque est devenu un réel problème métier pour les utilisateurs lorsqu'ils essayaient d'exploiter des solutions MDM. Vous devez avoir 30 personnes à l'étranger en charge de la gouvernance des données et tout le reste. Et ainsi, vous devez encore en avoir une partie, mais la vitesse et l’échelle à laquelle vous pouvez le traiter maintenant, vous donnent vraiment beaucoup plus de marge de manoeuvre.


Eric: Oui, c’est vraiment un très bon point. J'adore ce commentaire. Donc, vous avez le temps de le refaire à nouveau. C'est fantastique.


George: Ouais.


Eric: Eh bien, ça change la dynamique, non? Cela change votre façon de penser à ce que vous allez essayer. Je veux dire, je me souviens de cela il y a 18 ans dans l'industrie des effets spéciaux, parce que j'avais un client qui se trouvait dans cet espace. Et vous appuieriez sur les boutons pour le rendre et vous rentreriez chez vous. Et vous reviendriez peut-être samedi après-midi pour voir comment ça se passerait. Mais si vous vous êtes trompé, c'était très, très, très douloureux. Et maintenant, ce n’est presque pas - ce n’est même pas près d’être aussi douloureux, vous avez donc la possibilité d’essayer plus de choses. Je dois dire que je pense que c’est un très, très bon point.


George: C’est tout à fait vrai. Oui, et vous vous soulevez la jambe supplémentaire. Vous savez, dans le passé, votre travail était à mi-parcours et il échouait, vous avez gâché votre SOS. C'est ça.


Eric: C'est vrai. Et vous avez de gros problèmes, oui. C'est vrai.


George: C’est vrai. C'est vrai.


Eric: Keith, laissez-moi vous en donner un. Je me souviens d’avoir eu une entrevue avec votre CIL, Keith Collins, je crois, de retour, je pense, 2011 peut-être. Et il a beaucoup parlé de la direction prise par SAS en ce qui concerne la collaboration avec les clients pour intégrer les analyses dérivées de SAS aux systèmes opérationnels. Et bien sûr, nous avons entendu Mike Ferguson parler de l’importance de la mémoire. L'idée ici est que vous souhaitez pouvoir intégrer ces éléments à vos opérations. Vous ne voulez pas d’analyse en vase clos, déconnectée de l’entreprise. Cela n’a aucune valeur.


Si vous souhaitez une analyse pouvant directement impacter et optimiser les opérations. Et si je regarde en arrière - et je dois dire que j’ai pensé que c’était une bonne idée à ce moment-là - cela me semble être une idée vraiment très intelligente, rétrospectivement. Et je suppose que c’est un réel avantage pour vous. Et bien sûr, ce grand héritage, cette base d'installation énorme et le fait que vous ayez mis l'accent sur l'intégration de ces analyses dans des systèmes opérationnels, ce qui signifie maintenant - et d'accord, cela va prendre un certain travail - je suis sûr que vous ' y travaillons assez fort. Mais à présent, vous pouvez tirer parti de toutes ces innovations et en tirer le meilleur parti pour les rendre opérationnelles avec vos clients. Est-ce une évaluation juste?


Keith: Oui, absolument. Le concept est que vous obtenez cette idée de conception décisionnelle ou de science décisionnelle qui est, vous le savez, dans une certaine mesure, quelque chose de scientifique, de type exploratoire. À moins que vous ne puissiez faire de l'ingénierie sur le processus pour vraiment… Si vous envisagez de développer une voiture, vous avez des concepteurs qui fabriquent cette belle voiture, mais ce n'est pas avant que les ingénieurs mettent ce plan en place et fabriquent un produit réellement viable devant vous. peut réellement mettre les choses en place, et c'est essentiellement ce que SAS a fait. Il a fusionné les décisions - processus de conception de décision et processus d’ingénierie de décision - de sorte que, lorsque vous parlez des accélérateurs, les accélérateurs de scoring en particulier, vous savez, si vous prenez un modèle que vous avez développé et que vous pouvez le déployer. sur Teradata, ou transmettez-le à Oracle ou à Hadoop, sans interruption de service pour le développement de modèles, afin de les déployer. C’est la clé, car les modèles dégradent avec le temps la précision de ces modèles. Donc, plus vous mettez de temps à prendre cela et à le mettre en production, plus la perte de précision du modèle est grande.


Ensuite, vous voulez pouvoir surveiller et gérer ce processus au fil du temps. Vous souhaitez déprécier les modèles lorsqu'ils deviennent vieux et imprécis. Vous voulez l'examiner, en vérifier l'exactitude dans le temps et les reconstruire. Nous avons donc des outils de gestion de modèles qui s’ajoutent à cela, qui permettent de vraiment suivre les métadonnées autour du processus modélisé. Et les gens ont dit que la modélisation, vous savez, ce genre de concept est comme une fabrique de modèles, ou ce que vous voulez appeler. Le problème, c’est de mettre les métadonnées et la gestion dans le processus et c’est là que se trouvent les trois choses les plus importantes: nous aidons les gens à gagner de l’argent, à économiser de l’argent et à les garder hors de prison.


Eric: Ce dernier est assez gros aussi. Je cherche à éviter tout ça. Alors parlons de ...Je pose une dernière question. Peut-être que vous pouvez tous les deux sauter sur cette question. L'hétérogénéité de notre monde ne fera qu'augmenter, me semble-t-il. Je pense que nous allons certainement assister à une cristallisation autour des environnements de cloud hybride. Néanmoins, vous allez voir beaucoup d’acteurs majeurs rester dans les parages. IBM ne va nulle part. Oracle ne va nulle part. SAP ne va nulle part. Et il y a tellement d'autres vendeurs impliqués dans ce jeu.


En outre, du côté opérationnel, vous avez littéralement des milliers et des milliers de types différents d’applications. Et j’ai entendu - la plupart d’entre vous en ont parlé, mais je pense que vous seriez tous les deux d’accord avec ce que j’ai dit. Nous avons constaté cette tendance en termes de puissance de calcul dans les moteurs analytiques, l’architecture. Les entreprises discutent depuis des années de leur capacité à exploiter les autres moteurs et à gérer une sorte de point d’orchestration. Et je suppose, George, je vais vous le lancer en premier. Il me semble que quelque chose ne va pas changer. Nous allons avoir cet environnement hétérogène, ce qui signifie qu'il y a des choses comme le CRM en temps réel, la qualité des données et la gouvernance des données. En tant que fournisseur, vous devrez vous connecter à tous ces outils. Et c’est ce que les clients vont vouloir. Ils ne vont pas vouloir quelque chose qui fonctionne bien avec ces outils et qui ne l’est pas si bien avec ces outils. Ils vont vouloir la Suisse du MDM et du CRM, non?


George: C’est vrai. Et c’est intéressant, car nous l’avons beaucoup embrassé. L’histoire de l’espace en fait partie. Et évidemment, nous travaillions déjà sur toutes les autres bases de données, les Teradatas et les morceaux du monde. Et puis, dans le processus de mise en œuvre, plus précisément comme nous l’avons fait, pour qu’il en soit ainsi, vous avez cette étendue dans toutes ces bases de données. Ce qui est intéressant, c’est que certains de nos clients sont résolus à éliminer toutes les bases de données relationnelles. Et c’est intéressant. Vous savez, je veux dire, c’est bien. C'est intéressant. Mais je ne vois tout simplement pas que cela se produit réellement dans une grande entreprise. Je ne le vois pas arriver pendant longtemps. Donc, je pense que l’hybride est là depuis longtemps et que notre plate-forme de messagerie est intégrée à notre application de gestion de campagnes. Nous l'avons en fait spécifiquement conçu. Nous avons maintenant publié une version qui fait cela et qui peut se connecter maintenant à l'environnement de données hybride et interroger Hadoop, ou interroger n'importe quelle base de données, toute base de données analytique. Je pense donc que ce n’est que la vague de l’avenir. Et je conviens que la virtualisation jouera certainement un rôle important à cet égard, mais nous nous contentons de passer directement aux données de toutes nos applications.


Eric: D'accord, génial. Et, Keith, je vais vous le faire savoir. Que pensez-vous du monde hétérogène auquel nous sommes confrontés en agissant comme une sorte de pied?


Keith: Ouais, c’est vraiment fascinant. Je pense que ce que nous trouvons plus - pas seulement du côté de la gestion des données - mais ce qui est vraiment fascinant à l’heure actuelle, c’est la nature open source de la base analytique. Ainsi, nous voyons des organisations telles que, ou des technologies telles que Spark, intégrer, et des personnes utilisant Python et R et toutes ces autres technologies open source. Je pense que cela pourrait être interprété comme une sorte de conflit ou une menace dans une certaine mesure. Mais la réalité est que nous avons des compliments vraiment merveilleux avec toutes ces technologies à source ouverte. Je veux dire, d’une part, nous opérons au-dessus de plates-formes open source, pour l’amour de Dieu.


Mais aussi, comme pouvoir intégrer, par exemple, un modèle R dans un paradigme SAS, vous pouvez utiliser le meilleur des deux mondes, non? Ainsi, nous savons que certaines des expériences dans le monde académique et certains travaux de développement de modèles sont extraordinaires et extrêmement utiles dans le processus de développement de modèles. Mais aussi, si vous pouviez associer cela à un outil de type production, il effectue beaucoup de nettoyage, de qualité, de contrôle et de contrôle et de contrôle du traitement des données cédées au modèle, il a été préparé correctement pour qu'il n'échoue pas. à l'exécution. Et ensuite, être capable de faire des choses comme des modèles champion challenger avec des modèles open-source. C’est ce que nous cherchons à permettre et qui fait partie de cet écosystème vraiment hétérogène de toutes ces technologies. Ouais, c’est donc plus - pour nous, il s’agit davantage d’adopter ces technologies et de rechercher les compliments.


Eric: Eh bien, ça a été fantastique, les gars. Nous avons passé un peu de temps ici, mais nous aimerions poser le plus de questions possible. Nous allons transmettre le fichier de questions-réponses à nos présentateurs aujourd'hui. Donc, si aucune des questions que vous avez posées n’a obtenu de réponse, nous nous assurerons qu’elle obtienne une réponse. Et les gars, ça termine pour 2014. À la radio DM demain et la semaine prochaine, et puis tout est terminé et c’est une pause des vacances.


Un grand merci à vous tous pour votre temps et votre attention, pour avoir passé au travers de tous ces webcasts merveilleux. Nous avons une excellente année pour 2015. Nous vous parlerons bientôt, chers amis. Merci encore. Nous allons nous en occuper. Bye Bye.