Par Techopedia Staff, 2 juin 2016
À retenir: l' écosystème Hadoop est utilisé sur les mainframes pour traiter rapidement et efficacement les mégadonnées.
Vous n'êtes actuellement pas connecté. Veuillez vous connecter ou vous inscrire pour voir la vidéo.
Eric Kavanagh: D'accord mesdames et messieurs, il est quatre heures de l'Est un jeudi, et de nos jours, cela signifie bien sûr qu'il est temps pour Hot Technologies. Oui, je m'appelle Eric Kavanagh. Je serai votre modérateur pour le séminaire Web d'aujourd'hui. Ce sont de bonnes choses, les gens, "Big Iron, Meet Big Data" - J'adore ce titre - "Libération des données mainframe avec Hadoop et Spark". Nous allons parler d'anciennes et de nouvelles. Hou la la! Nous couvrons le spectre de tout ce dont nous avons parlé au cours des 50 dernières années de l'informatique d'entreprise. Spark rencontre le mainframe, je l'adore.
Il y a vraiment une place dans la tienne qui me concerne. L'année est chaude. Nous parlons de sujets d'actualité dans cette série parce que nous essayons vraiment d'aider les gens à comprendre certaines disciplines, certains espaces. Que signifie, par exemple, avoir une plateforme analytique? Que signifie libérer les mégadonnées des mainframes? Que signifie tout ça? Nous essayons de vous aider à comprendre des types de technologies spécifiques, où elles s'intègrent dans le mélange et comment vous pouvez les utiliser.
Nous avons aujourd'hui deux analystes, puis bien sûr Tendü Yogurtçu de Syncsort. C'est une visionnaire dans notre espace, très heureuse de l'avoir en ligne aujourd'hui, avec nos propres Dez Blanchfield et Dr. Robin Bloor. Je vais dire quelques mots rapides. Premièrement, vous jouez un rôle important dans ce processus, alors n'hésitez pas à poser de bonnes questions. Nous aimerions les atteindre lors de la partie Q&R de la webémission, qui se déroule généralement à la fin de l'émission. Et tout ce que j'ai à dire, c'est que nous avons beaucoup de bon contenu, donc je suis ravi d'entendre ce que ces garçons ont à dire. Et avec ça, je vais céder la parole à Dez Blanchfield. Dez, la parole est à vous, emportez-la.
Dez Blanchfield: Merci, Eric, et merci à tous d'être venus aujourd'hui. Je suis donc très excité quand j'ai la chance de parler de l'une de mes choses préférées dans le monde, les mainframes. Ils ne reçoivent pas beaucoup d'amour de nos jours. Mon point de vue est que l'ordinateur central était la plate-forme originale de Big Data. Certains diraient qu'ils étaient le seul ordinateur à l'époque et c'est un argument valable à faire valoir, mais depuis plus de 60 ans maintenant, ils ont vraiment été la salle des machines de ce que les mégadonnées ont récemment été populaires. Et je vais vous emmener dans un petit voyage sur pourquoi je crois que c'est le cas.
Nous avons vu un voyage dans les piles de matériel technologique dans le contexte des changements de mainframes de l'image que vous voyez à l'écran maintenant. Il s'agit d'un ancien ordinateur central FACOM, l'un de mes favoris. Nous sommes entrés dans la grande phase du fer, la fin des années 90 et le boom du dot-com. Il s'agit du Sun Microsystems E10000. Cette chose était un monstre absolu avec 96 CPU. À l'origine 64, mais il pourrait être mis à niveau à 96 CPU. Chaque CPU peut exécuter 1 024 threads. Chaque thread peut être au taux d'application en même temps. C'était juste monstrueux et il a propulsé le boom du dot-com. Ce sont toutes les grandes licornes comme nous les appelons, maintenant nous courons, et pas seulement les grandes entreprises, certains des grands sites Web.
Et puis nous nous sommes retrouvés avec ce modèle de PC de base standard. Nous avons juste attaché beaucoup de machines bon marché ensemble et nous avons créé un cluster et nous avons abordé le grand défi du fer et ce qui est devenu le big data, en particulier sous la forme du projet Hadoop qui a émergé du moteur de recherche open source, Nutch. Et nous avons essentiellement recréé le mainframe et beaucoup de petits processeurs collés ensemble et pouvant agir comme des chemins L et sous la forme d'exécuter des travaux séparés ou des parties de travaux et ils étaient assez efficaces à bien des égards. Moins cher si vous avez commencé plus petit, mais invariablement bon nombre de ces grands clusters sont devenus plus chers qu'un ordinateur central.
Mon point de vue sur ces choses est que, dans la course du boom des dot-com à ce qui est devenu le Web 2.0 et à la poursuite des licornes, nous avons oublié qu'il existe toujours cette plate-forme qui alimente bon nombre de nos plus grands systèmes critiques. Quand nous pensons à ce qui fonctionne sur les plateformes mainframe. Il s'agit essentiellement du Big Data, en particulier du cheval de bataille des données, mais certainement du Big Data. Nous utilisons tous les jours des systèmes traditionnels d'entreprise et de gouvernement tels que la banque, la gestion de patrimoine et l'assurance.
Systèmes de réservation et de gestion des vols des compagnies aériennes, en particulier la gestion des vols lorsque le temps réel est critique. Presque chaque état et gouvernement fédéral à un moment donné a eu un ordinateur central et invariablement beaucoup en ont encore. Vente au détail et fabrication. Certains des anciens logiciels qui existent et qui ne sont jamais partis. Continue d'alimenter les environnements de fabrication et certainement de vendre à grande échelle. Systèmes médicaux. Les systèmes de défense, certainement les systèmes de défense.
Ces dernières semaines, j'ai lu de nombreux articles sur le fait que certains des systèmes de contrôle des missiles fonctionnent toujours sur de vieux ordinateurs centraux pour lesquels ils ont du mal à trouver des pièces. Ils découvrent comment passer à de nouveaux mainframes. Systèmes de transport et de logistique. Ceux-ci peuvent ne pas ressembler à des sujets sexy, mais ce sont les sujets que nous traitons quotidiennement à travers les lignes. Et certains très grands environnements de télécommunications fonctionnent toujours sur des plates-formes mainframe.
Lorsque vous pensez aux types de données qui s'y trouvent, ils sont tous essentiels à la mission. Ce sont des plateformes vraiment importantes et des plateformes que nous tenons pour acquises tous les jours et qui, à bien des égards, rendent la vie possible. Alors, qui utilise toujours un ordinateur central et qui sont toutes ces personnes qui s'accrochent à ces grandes plates-formes et détiennent toutes ces données? Eh bien, comme je l'ai dit ici, je pense qu'il est facile de se laisser berner par le passage des médias de gros fer à repasser à des clusters ordinaires ou à des PC bon marché ou à des machines x86, en pensant que le mainframe est mort et est parti. Mais les données indiquent que l'ordinateur central n'a jamais disparu et qu'en fait, il est là pour rester.
Les recherches que j'ai rassemblées ici au cours des deux dernières semaines ont montré que 70% des données des entreprises, en particulier des grandes entreprises, résident toujours sur un ordinateur central d'une certaine forme. Soixante et onze pour cent des Fortune 500 exploitent encore quelque part des systèmes commerciaux de base sur des mainframes. En fait, ici en Australie, nous avons un certain nombre d'organisations qui ont un centre de données au milieu d'une ville. C'est un véritable ordinateur clandestin efficace, et le nombre de mainframes qui y fonctionnent, coche et fait son travail avec plaisir. Et très peu de gens savent que se promener dans les rues, juste sous leurs pieds dans une partie particulière de la ville, il y a cet énorme centre de données rempli de mainframes. Quatre-vingt-douze des 100 banques du monde, les 100 premières banques qui existent, gèrent encore des systèmes bancaires sur des ordinateurs centraux. Vingt-trois des 25 principales chaînes de vente au détail dans le monde utilisent des mainframes pour continuer à gérer leurs systèmes de gestion de vente au détail sur les plateformes EIP et BI.
Il est intéressant de noter que 10 des 10 principaux assureurs exploitent toujours leurs plates-formes sur le mainframe et qu'ils alimentent en fait leurs services cloud sur le mainframe. Si vous utilisez une interface Web ou une application mobile dans un endroit où il existe un middleware, qui parle en fait à quelque chose de vraiment lourd et gros à l'arrière.
J'ai trouvé encore plus de 225 agences gouvernementales locales et étatiques dans le monde fonctionnant sur des plates-formes mainframe. Je suis sûr qu'il y a beaucoup de raisons à cela. Peut-être qu'ils n'ont pas le budget pour envisager un nouveau fer à repasser, mais c'est une énorme empreinte d'environnements très grands fonctionnant sur ordinateur central avec des données très critiques. Et comme je l'ai mentionné plus tôt, la plupart des pays exploitent toujours leurs principaux systèmes de défense sur ordinateur central. Je suis sûr qu'à bien des égards, ils essaient de descendre, mais voilà.
En 2015, IDC a mené une enquête et 350 des DSI interrogés ont déclaré qu'ils possédaient et géraient encore du gros fer sous forme de mainframes. Et cela m'a frappé qu'il est probable que ce soit plus que le nombre de clusters Hadoop à grande échelle actuellement en cours de production dans le monde - une petite statistique intéressante là-bas. Je vais aller de l'avant et valider cela, mais c'était un grand nombre. Trois cent cinquante DSI ont déclaré qu’un ou plusieurs ordinateurs centraux étaient toujours en production.
L'année dernière, 2015, IBM nous a offert le puissant Z13, la 13e itération de leur plate-forme mainframe. Les médias se sont déchaînés à ce sujet parce qu'ils étaient stupéfaits qu'IBM fasse encore des mainframes. Quand ils ont levé le capot et ont jeté un coup d'œil à ce qu'il y avait sous la chose, ils ont réalisé que c'était en fait à égalité avec presque toutes les plateformes modernes qui nous avaient enthousiasmés sous la forme de mégadonnées, Hadoop et certainement les clusters. Cette chose a couru nativement Spark et maintenant Hadoop. Vous pouvez exécuter des milliers et des milliers de machines Linux dessus et cela ressemblait à tout autre cluster. C'était une machine assez étonnante.
Un certain nombre d'organisations ont repris ces choses et en fait, j'ai fait quelques données sur le nombre de ces machines qui prennent. Maintenant, j'ai l'impression que le terminal texte 3270 a été remplacé par des navigateurs Web et des applications mobiles depuis un certain temps et il y a beaucoup de données qui le supportent. Je pense que nous entrons maintenant dans une ère où nous avons réalisé que ces mainframes ne disparaissent pas et qu'il y a une quantité substantielle de données à leur sujet. Et donc ce que nous faisons maintenant, c'est simplement ajouter ce que j'appelle des outils d'analyse standard. Ce ne sont pas des applications personnalisées. Ce sont des choses sur mesure uniques. Ce sont des choses que vous pouvez littéralement acheter dans une boîte emballée en soi et vous connecter à votre ordinateur central et faire des analyses.
Comme je l'ai déjà dit, le mainframe existe depuis plus de 60 ans, en fait. Lorsque nous pensons à la durée, c'est plus long que la carrière de la plupart des professionnels de l'informatique. Et en fait probablement même une partie de leur vie. En 2002, IBM a vendu 2 300 ordinateurs centraux. En 2013, ce chiffre est passé à 2 700 ordinateurs centraux. Cela représente 2 700 ventes de mainframes en un an en 2013. Je n'ai pas pu obtenir de données précises sur 2015, mais j'imagine que cela se rapproche rapidement des 3 000 unités vendues par an en 2015, 2013. Et j'ai hâte de pouvoir le confirmer.
Avec la sortie du Z13, la 13ème itération d'une plate-forme mainframe, qui je pense leur a coûté environ 1, 2 ou 1, 3 milliard de dollars pour se développer à partir de zéro, IBM c'est-à-dire, voici une machine qui ressemble et se sent comme n'importe quel autre cluster qui nous avons aujourd'hui, et exécute nativement Hadoop et Spark. Et peut certainement être connecté à d'autres outils d'analyse et de Big Data ou être invariablement connecté à l'un de vos clusters Hadoop existants ou nouveaux. J'ai cette opinion qu'inclure la plate-forme mainframe dans votre stratégie de Big Data est un must. Évidemment, si vous en avez un, vous avez beaucoup de données et vous voulez savoir comment les retirer. Et ils sont laissés pour ramasser la poussière de plusieurs façons, mentalement et émotionnellement dans le monde des affaires, mais ils sont là pour rester.
La connectivité et les interfaces de tous vos outils d'analyse avec les données hébergées sur le mainframe devraient être un élément clé de votre entreprise et en particulier des plans de Big Data du gouvernement. Et invariablement, maintenant, les logiciels les remarquent, les examinent longuement et réalisent ce qu'il y a à l'intérieur de ces choses et connectent les esprits qui commencent à avoir un peu de perspicacité et un peu de sens pour ce qui est réellement sous le capot. Et avec cela, je vais céder la parole à mon cher collègue, le Dr Robin Bloor et il ajoutera à ce petit voyage. Robin, emporte-le.
Robin Bloor: Eh bien, merci. D'accord, puisque Dez a chanté la chanson du mainframe, je vais entrer dans ce que je pense qui se passe en termes de l'ancien monde mainframe et du nouveau monde Hadoop. Je suppose que la grande question ici est de savoir comment gérer toutes ces données? Je ne pense pas que l'ordinateur central soit contesté en ce qui concerne sa capacité de Big Data - sa capacité de Big Data est extrêmement, comme l'a souligné Dez, il est extrêmement capable. En fait, vous pouvez y placer des clusters Hadoop. Là où il est contesté, c'est en termes d'écosystème et je vais en quelque sorte m'étendre là-dessus.
Voici un positionnement du mainframe. Il a un coût d'entrée élevé et ce qui s'est réellement passé dans le passé, depuis le milieu des années 90, lorsque la popularité des mainframes a commencé à baisser, il a eu tendance à perdre son bas de gamme, ces personnes qui avaient acheté des mainframes bon marché et ce n'était pas le cas. 't vraiment économique particulièrement pour ces gens. Mais plus haut en fait dans le milieu de gamme et le haut de gamme du mainframe, il était toujours, et c'est en fait, incroyablement peu coûteux.
Il a été, il faut le dire, sauvé par Linux car Linux implémenté sur un mainframe permettait bien sûr d'exécuter toutes les applications Linux. Beaucoup d'applications Linux y sont allées avant que les mégadonnées ne soient même un mot, ou deux mots, je suppose. C'est en fait une plate-forme assez excellente pour le cloud privé. De ce fait, il peut participer aux déploiements de cloud hybride. L'un des problèmes est que les compétences mainframe sont rares. Les compétences de mainframe qui existent vieillissent en fait dans le sens où les gens quittent l'industrie pour la retraite année après année et ils ne sont que remplacés en termes de nombre de personnes. C'est donc un problème. Mais c'est toujours une informatique peu coûteuse.
Le domaine où il a été contesté est bien sûr toute cette histoire Hadoop. C'est une photo de Doug Cutting avec l'éléphant Hadoop original. L'écosystème Hadoop est - et il restera - l'écosystème dominant des mégadonnées. Il offre une meilleure évolutivité que le mainframe ne peut réellement atteindre et son coût en tant que magasin de données est long. L'écosystème Hadoop évolue. La meilleure façon de penser à ce sujet est une fois qu'une plate-forme matérielle particulière et l'environnement d'exploitation avec elle deviennent dominants, puis l'écosystème prend vie. Et cela s'est produit avec le mainframe IBM. Eh bien, c'est arrivé plus tard avec le Digital VAX, avec les serveurs de Sun, avec Windows, avec Linux.
Et ce qui s'est passé, c'est que Hadoop, auquel je pense toujours, ou que j'aime penser, comme une sorte d'environnement distribué pour les données, l'écosystème évolue à un rythme incroyable. Je veux dire si vous mentionnez simplement les diverses contributions impressionnantes qui sont open source, Spark, Flink, Kafka, Presto, puis vous ajoutez à cela certaines des bases de données, les capacités NoSQL et SQL qui reposent maintenant sur Hadoop. Hadoop est l'écosystème le plus actif qui existe réellement, certainement dans l'informatique d'entreprise. Mais si vous voulez le traiter comme une base de données, cela ne peut tout simplement pas être comparé à ce que j'ai tendance à considérer comme de vraies bases de données, en particulier dans l'espace d'entrepôt de données. Et cela explique dans une certaine mesure le succès d'un certain nombre de grandes bases de données NoSQL qui ne fonctionnent pas sur Hadoop comme CouchDB et ainsi de suite.
En tant que lac de données, son écosystème est beaucoup plus riche que toute autre plate-forme et il ne sera pas remplacé par cela. Son écosystème n'est pas seulement l'écosystème open-source. Il y a maintenant un nombre considérable de membres logiciels qui ont des produits qui sont fondamentalement conçus pour Hadoop ou qui ont été importés dans Hadoop. Et ils viennent de créer un écosystème où rien ne peut rivaliser avec lui en termes d'étendue. Et cela signifie vraiment que c'est devenu la plate-forme pour l'innovation du big data. Mais à mon avis, c'est encore immature et nous pourrions avoir de longues discussions sur ce qui est et n'est pas, disons, opérationnel avec Hadoop, mais je pense que la plupart des gens qui regardent ce domaine particulier savent bien que Hadoop a des décennies de retard sur l'ordinateur central. en termes de capacité opérationnelle.
Le lac de données en évolution. Le lac de données est une plate-forme de toute définition et si vous pensez qu'il existe une couche de données dans l'informatique d'entreprise, il est très facile de la penser en termes de bases de données fixes et du lac de données constituant la couche de données. Les applications de Data Lake sont nombreuses et variées. J'ai ici un diagramme qui passe simplement en revue les différentes choses qui doivent être faites si vous utilisez Hadoop comme zone de transit ou Hadoop et Spark comme zone de transit. Et vous avez tout cela - lignée de données, nettoyage des données, gestion des métadonnées, découverte des métadonnées - il peut être utilisé pour ETL lui-même mais nécessite souvent ETL pour introduire les données. Gestion des données de base, définitions commerciales des données, gestion des services de ce qui se passe dans Hadoop, la gestion du cycle de vie des données et ETL hors de Hadoop, et vous avez également des applications d'analyse directe que vous pouvez exécuter sur Hadoop.
Et c'est pourquoi il est devenu très puissant et où il a été implémenté et mis en œuvre avec succès, normalement il a au moins une collection de ces types d'applications en cours d'exécution. Et la plupart de ces applications, en particulier celles dont j'ai été informé, ne sont tout simplement pas disponibles sur le mainframe pour le moment. Mais vous pouvez les exécuter sur le mainframe, sur un cluster Hadoop qui s'exécutait dans une partition du mainframe.
Le lac de données devient, à mon avis, la zone de transfert naturelle pour l'analyse de base de données rapide et pour la BI. Il devient l'endroit où vous prenez les données, que ce soit des données d'entreprise ou des données externes, gâtez-les jusqu'à ce qu'elles soient, disons, assez propres à utiliser et bien structurées à utiliser, puis vous les transmettez. Et tout cela est encore à ses balbutiements.
L'idée, à mon avis, de la coexistence mainframe / Hadoop, la première chose est que les grandes entreprises sont peu susceptibles d'abandonner le mainframe. En fait, les indications que j'ai vues récemment impliquent un investissement croissant dans le mainframe. Mais ils n'ignoreront pas non plus l'écosystème Hadoop. Je constate que 60% des grandes entreprises utilisent Hadoop même si beaucoup d'entre elles ne sont en fait que du prototypage et de l'expérimentation.
L'énigme est alors: «Comment faire coexister ces deux choses?», Car elles vont devoir partager des données. Les données qui sont introduites dans le lac de données doivent être transférées vers le mainframe. Les données qui sont sur le mainframe peuvent devoir aller au lac de données ou via le lac de données afin d'être jointes à d'autres données. Et ça va arriver. Et cela signifie qu'il nécessite un transfert de données rapide / capacité ETL. Il est peu probable que les charges de travail soient partagées dynamiquement dans, disons, un environnement mainframe ou avec quelque chose dans un environnement Hadoop. Ce seront des données partagées. Et la majorité des données résideront inévitablement sur Hadoop simplement parce que c'est la plate-forme la moins chère pour cela. Et le traitement analytique de bout en bout résidera probablement là aussi.
En résumé, nous devons finalement penser en termes de couche de données d'entreprise, qui pour de nombreuses entreprises comprendra le mainframe. Et cette couche de données doit être gérée de manière proactive. Sinon, les deux ne coexisteront pas bien. Je peux te passer le ballon Eric.
Eric Kavanagh: Encore une fois, Tendü je viens de vous faire le présentateur, alors retirez-le.
Tendü Yogurtçu: Merci, Eric. Merci de me recevoir. Salut tout le monde. Je parlerai de l'expérience de Syncsort avec les clients en relation avec la façon dont nous considérons les données comme un atout dans l'organisation, du système central au big data sur les plateformes d'analyse. Et j'espère que nous aurons également du temps à la fin de la session pour poser des questions au public car c'est vraiment la partie la plus précieuse de ces webémissions.
Pour les personnes qui ne savent pas ce que fait Syncsort, Syncsort est une société de logiciels. Nous existons depuis plus de 40 ans. Commencé du côté mainframe et nos produits s'étendent du mainframe à Unix aux plateformes de Big Data, y compris Hadoop, Spark, Splunk, à la fois sur site et dans le cloud. Nous nous sommes toujours concentrés sur les produits de données, les produits de traitement et d'intégration de données.
Notre stratégie en matière de big data et Hadoop a vraiment été de faire partie de l'écosystème dès le premier jour. En tant que propriétaires de fournisseurs qui se sont vraiment concentrés sur le traitement des données avec des moteurs très légers, nous pensions qu'il y avait une grande opportunité de participer à Hadoop en devenant une plate-forme de traitement des données et de faire partie de cette architecture d'entrepôt de données de nouvelle génération pour l'organisation. Nous contribuons aux projets open source Apache depuis 2011, à commencer par MapReduce. Ont été dans le top 10 pour Hadoop Version 2, et ont en fait participé à plusieurs projets incluant également des packages Spark, certains de nos connecteurs sont publiés dans des packages Spark.
Nous tirons parti de notre moteur de traitement de données très léger, qui est des métadonnées entièrement basées sur des fichiers plats, et qui correspond très bien aux systèmes de fichiers distribués comme Hadoop Distributed File System. Et nous tirons parti de notre héritage sur le mainframe, de notre expertise en algorithmes lors de la mise en marché de nos produits de Big Data. Et nous travaillons en étroite collaboration avec les principaux fournisseurs, les principaux acteurs ici, dont Hortonworks, Cloudera, MapR, Splunk. Hortonworks a récemment annoncé la revente de notre produit pour l'intégration ETL avec Hadoop. Avec Dell et Cloudera, nous avons un partenariat très étroit qui revend également notre produit ETL dans le cadre de leur dispositif de Big Data. Et avec Splunk, nous publions une télémétrie mainframe et des données de sécurité dans les tableaux de bord Splunk. Nous avons un partenariat étroit.
Que pense chaque dirigeant de niveau C? C'est vraiment: «Comment puis-je accéder à mes ressources de données?» Tout le monde parle de Big Data. Tout le monde parle de Hadoop, Spark, la prochaine plate-forme informatique qui peut m'aider à créer une agilité commerciale et à ouvrir de nouvelles applications transformatrices. Nouvelles opportunités de mise sur le marché. Chaque dirigeant pense: "Quelle est ma stratégie de données, quelle est mon initiative en matière de données, et comment puis-je m'assurer de ne pas rester derrière mes concurrents, et je suis toujours sur ce marché au cours des trois prochaines années?" Nous voyez cela comme nous parlons à nos clients, comme nous parlons à notre base de clients mondiale, qui est assez grande, comme vous pouvez l'imaginer, puisque nous existons depuis un certain temps.
Alors que nous parlons avec toutes ces organisations, nous voyons également cela dans la pile technologique dans la perturbation qui s'est produite avec Hadoop. C'est vraiment pour satisfaire cette demande de données en tant qu'atout. Tirer parti de tous les actifs de données d'une organisation. Et nous avons vu l'architecture de l'entrepôt de données d'entreprise évoluer de telle sorte que Hadoop est désormais la nouvelle pièce maîtresse de l'architecture de données moderne. Et la plupart de nos clients, que ce soit les services financiers, que ce soit l'assurance, le télécom du commerce de détail, les initiatives sont généralement soit nous trouvons que Hadoop en tant que service ou les données en tant que service. Parce que tout le monde essaie de rendre les actifs de données disponibles pour leurs clients externes ou internes. Et dans certaines organisations, nous voyons des initiatives comme presque un marché de données pour leurs clients.
Et l'une des premières étapes pour y parvenir consiste à créer un concentrateur de données d'entreprise. Parfois, les gens l'appelleront un lac de données. La création de ce centre de données d'entreprise n'est en fait pas aussi simple qu'il y paraît, car cela nécessite vraiment d'accéder et de collecter pratiquement toutes les données de l'entreprise. Et ces données proviennent maintenant de toutes les nouvelles sources comme les capteurs mobiles ainsi que les bases de données héritées et elles sont en mode batch et en mode streaming. L'intégration des données a toujours été un défi, cependant, avec le nombre et la variété des sources de données et les différents styles de livraison, que ce soit par lots ou en streaming en temps réel, c'est encore plus difficile maintenant qu'il y a cinq ans, il y a dix ans. Nous l'appelons parfois «ce n'est plus l'ETL de votre père».
Nous parlons donc des différents actifs de données. Alors que les entreprises tentent de donner un sens aux nouvelles données, aux données qu'elles collectent à partir des appareils mobiles, que ce soit les capteurs d'un constructeur automobile ou les données utilisateur d'une entreprise de jeux mobiles, elles doivent souvent référencer les données les plus importantes dans l'entreprise, qui est par exemple une information client. Ces ressources de données les plus critiques vivent souvent sur le mainframe. La corrélation des données mainframe avec ces nouvelles sources émergentes, collectées dans le cloud, collectées via mobile, collectées sur la chaîne de fabrication d'un constructeur automobile japonais, ou des applications internet des objets, doivent donner un sens à ces nouvelles données en référençant leurs anciens ensembles de données. Et ces ensembles de données hérités sont souvent sur le mainframe.
Et si ces entreprises ne sont pas en mesure de le faire, ne sont pas en mesure d'exploiter les données du mainframe, il y a une opportunité manquée. Ensuite, les données en tant que service, ou l'exploitation de toutes les données d'entreprise ne sont pas vraiment exploiter les actifs les plus critiques de l'organisation. Il y a aussi la partie télémétrie et données de sécurité car presque toutes les données transactionnelles vivent sur le mainframe.
Imaginez que vous vous rendiez à un guichet automatique, je pense que l'un des participants a envoyé un message aux participants ici pour protéger le système bancaire, lorsque vous glissez votre carte que les données transactionnelles sont à peu près globalement sur le mainframe. Et la sécurisation et la collecte des données de sécurité et des données de télémétrie des mainframes et leur mise à disposition via des tableaux de bord Splunk ou autres, Spark, SQL, devient plus critique que jamais, en raison du volume des données et de la variété des données.
Les ensembles de compétences sont l'un des plus grands défis. Parce que d'une part, vous avez une pile de Big Data qui évolue rapidement, vous ne savez pas quel projet va survivre, quel projet ne va pas survivre, devrais-je embaucher des développeurs Hive ou Pig? Dois-je investir dans MapReduce ou Spark? Ou la prochaine chose, Flink, quelqu'un a dit. Dois-je investir dans l'une de ces plateformes informatiques? D'une part, suivre l'écosystème en évolution rapide est un défi et, d'autre part, vous disposez de ces sources de données héritées. Les nouveaux ensembles de compétences ne correspondent pas vraiment et vous pourriez avoir un problème car ces ressources pourraient être en train de prendre leur retraite. Il y a un grand écart en termes de compétences de personnes qui comprennent ces piles de données héritées et qui comprennent la pile technologique émergente.
Le deuxième défi est la gouvernance. Lorsque vous accédez réellement à toutes les données d'entreprise sur toutes les plateformes, nous avons des clients qui ont exprimé des inquiétudes: «Je ne veux pas que mes données atterrissent. Je ne veux pas que mes données soient copiées à plusieurs endroits parce que je veux éviter autant que possible les multiples copies. Je veux avoir un accès de bout en bout sans y atterrir au milieu. »La gestion de ces données devient un défi. Et l'autre élément est que si vous accédez à des données qui goulot d'étranglement, si vous collectez la plupart de vos données dans le cloud et accédez et référencez des données héritées, la bande passante réseau devient un problème, une plate-forme de cluster. Il existe de nombreux défis en ce qui concerne la mise en place de cette initiative de Big Data et de plates-formes d'analyse avancées tout en tirant parti de toutes les données d'entreprise.
Ce que Syncsort offre, c'est que nous sommes qualifiés de «simplement les meilleurs», non pas parce que nous sommes simplement les meilleurs, mais nos clients nous considèrent vraiment comme les meilleurs pour accéder aux données mainframe et les intégrer. Nous prenons en charge tous les formats de données du mainframe et les rendons disponibles pour l'analyse de Big Data. Que ce soit sur Hadoop ou Spark ou sur la prochaine plate-forme informatique. Parce que nos produits isolent vraiment les complexités de la plate-forme informatique. En tant que développeur, vous développez potentiellement sur un ordinateur portable, en vous concentrant sur le pipeline de données et quelles sont les préparations de données, les étapes pour créer ces données pour l'analyse, la phase suivante, et prenez la même application dans MapReduce ou prenez-la même application dans Spark.
Nous avons aidé nos clients à le faire lorsque YARN est devenu disponible et ils ont dû déplacer leurs applications de MapReduce version 1 vers YARN. Nous les aidons à faire de même avec Apache Spark. Notre produit, la nouvelle version 9 fonctionne également avec Spark et est livré avec une optimisation dynamique qui isolera ces applications pour les futurs cadres informatiques.
Nous avons donc accès aux données de l'ordinateur central, qu'il s'agisse de fichiers VSAM, de DB2 ou de données de télémétrie, telles que les enregistrements SMF ou Log4j ou syslog, qui doivent être visualisées via les tableaux de bord Splunk. Et ce faisant, comme l'organisation peut tirer parti de leurs compétences existantes en ingénieur de données ou en compétences ETL, le temps de développement est considérablement réduit. En fait, avec Dell et Cloudera, il y avait un benchmark indépendant sponsorisé, et ce benchmark se concentrait sur le temps de développement que cela prend si vous faites du codage manuel ou utilisez d'autres outils tels que Syncsort, et c'était environ 60, 70 pour cent de réduction du temps de développement . Combler le fossé des ensembles de compétences entre les groupes, entre les hôtes de fichiers de données et également les hôtes de fichiers de données en termes de personnes.
Habituellement, l'équipe Big Data, ou l'équipe d'ingestion de données, ou l'équipe chargée de développer ces données en tant qu'architecture de service, ne parle pas nécessairement avec l'équipe mainframe. Ils veulent minimiser cette interaction presque dans de nombreuses organisations. En comblant cet écart, nous avons progressé. Et la partie la plus importante est vraiment de sécuriser l'ensemble du processus. Parce que dans l'entreprise, lorsque vous traitez ce type de données sensibles, il existe de nombreuses exigences.
Dans des secteurs hautement réglementés comme l'assurance et la banque, nos clients demandent: «Vous offrez cet accès aux données mainframe et c'est formidable. Pouvez-vous également me proposer de faire en sorte que ce format d'enregistrement codé EBCDIC soit conservé dans son format d'origine afin que je puisse satisfaire mes exigences d'audit? »Nous faisons donc comprendre à Hadoop et Apache Spark les données du mainframe. Vous pouvez conserver les données dans leur format d'enregistrement d'origine, faire votre plate-forme informatique de traitement et de distribution des niveaux et si vous devez les remettre, vous pouvez montrer que l'enregistrement n'est pas modifié et que le format d'enregistrement n'est pas modifié, vous pouvez vous conformer aux exigences réglementaires .
Et la plupart des organisations, lors de la création du concentrateur de données ou du lac de données, essaient également de le faire en un seul clic pour pouvoir mapper les métadonnées de centaines de schémas d'une base de données Oracle vers des tables Hive ou des fichiers ORC ou Parquet. devient nécessaire. Nous expédions des outils et nous fournissons des outils pour en faire un accès aux données en une seule étape, des travaux de génération automatique ou le mouvement des données, et des travaux de génération automatique pour faire le mappage des données.
Nous avons parlé de la connectivité, de la conformité, de la gouvernance et du traitement des données. Et nos produits sont disponibles à la fois sur site et dans le cloud, ce qui le rend vraiment très simple, car les entreprises n'ont pas besoin de penser à ce qui va se passer au cours des deux prochaines années si je décide d'aller complètement dans le cloud public contre hybride l'environnement, car certains clusters peuvent s'exécuter sur site ou dans le cloud. Et nos produits sont disponibles à la fois sur Amazon Marketplace, sur EC2, Elastic MapReduce et également sur un conteneur Docker.
Juste pour conclure, nous avons donc assez de temps pour les questions et réponses, il s'agit vraiment d'accéder à la gouvernance des données, de l'intégrer et de la respecter, tout en simplifiant tout cela. Et tout en simplifiant, «concevoir une fois et déployer n'importe où» au sens propre grâce à nos contributions open source, notre produit s'exécute nativement dans le flux de données Hadoop et nativement avec Spark, isolant les organisations de l'écosystème en évolution rapide. Et en fournissant un seul pipeline de données, une seule interface, à la fois pour le batch et le streaming.
Et cela aide également les organisations à évaluer parfois ces cadres, car vous voudrez peut-être réellement créer des applications et simplement exécuter sur MapReduce contre Spark et voir par vous-même, oui, Spark a cette promesse et fournit toutes les avancées sur les algorithmes itératifs qui fonctionnent pour le meilleur apprentissage automatique. et les applications d'analyse prédictive fonctionnent avec Spark, puis-je également faire effectuer mes charges de travail en continu et par lots sur cette infrastructure informatique? Vous pouvez tester différentes plates-formes informatiques à l'aide de nos produits. Et l'optimisation dynamique, que vous exécutiez sur un serveur autonome, sur votre ordinateur portable, dans Google Cloud par rapport à Apache Spark, est vraiment une grande proposition de valeur pour nos clients. Et c'était vraiment motivé par les défis qu'ils avaient.
Je vais juste couvrir une des études de cas. Voici la Guardian Life Insurance Company. Et l'initiative de Guardian était vraiment de centraliser leurs actifs de données et de les mettre à la disposition de leurs clients, de réduire le temps de préparation des données et ils ont dit que tout le monde parlait de la préparation des données occupant 80% du pipeline global de traitement des données et ils ont dit que cela prenait en fait environ 75 à 80 pour cent pour eux et ils voulaient réduire la préparation des données, les temps de transformation, les délais de mise sur le marché des projets d'analyse. Créez cette agilité en ajoutant de nouvelles sources de données. Et rendez cet accès centralisé aux données accessible à tous leurs clients.
Leur solution, y compris les produits Syncsort, consiste en ce moment à disposer d'un marché de données similaire à Amazon Marketplace pris en charge par un lac de données, qui est essentiellement Hadoop et une base de données NoSQL. Et ils utilisent nos produits pour apporter tous les actifs de données au lac de données, y compris DB2 sur le mainframe, y compris les fichiers VSAM sur le mainframe, et les sources de données héritées de la base de données ainsi que les nouvelles sources de données. Et à la suite de cela, ils ont centralisé les actifs de données réutilisables qui sont consultables, accessibles et disponibles pour leurs clients. Et ils sont vraiment capables d'ajouter les nouvelles sources de données et de servir leurs clients beaucoup plus rapidement et plus efficacement qu'auparavant. Et les initiatives d'analyse progressent même davantage du côté prédictif. Je vais donc faire une pause et j'espère que cela a été utile et si vous avez des questions pour moi sur l'un des sujets connexes, n'hésitez pas.
Eric Kavanagh: Bien sûr, et Tendü, je vais juste en ajouter un. J'ai reçu un commentaire d'un membre du public disant simplement: «J'aime cette« conception une fois, déployez-la n'importe où ».» Pouvez-vous creuser en quelque sorte comment c'est vrai? Je veux dire, qu'avez-vous fait pour permettre ce genre d'agilité et y a-t-il une taxe? Comme lorsque nous parlons de virtualisation, par exemple, il y a toujours un peu de taxe sur les performances. Certaines personnes disent deux pour cent, cinq pour cent 10 pour cent. Ce que vous avez fait pour activer la conception une fois, déployer n'importe où - comment faites-vous et y a-t-il une taxe associée en termes de performances?
Tendü Yogurtçu: Bien sûr, merci. Non, car contrairement à certains autres fournisseurs, nous ne générons pas vraiment Hive ou Pig ou un autre code qui n'est pas natif de nos moteurs. C'est là que nos contributions open source ont joué un rôle énorme, car nous avons travaillé en étroite collaboration avec les fournisseurs Hadoop, Cloudera, Hortonworks et MapR et en raison de nos contributions open source, notre moteur fonctionne en fait nativement dans le cadre du flux, dans le cadre du flux Hadoop, dans le cadre du Spark.
Ce qui se traduit aussi, nous avons cette optimisation dynamique. C'est quelque chose qui est venu à la suite de la contestation de nos clients avec les cadres informatiques. Alors qu'ils entraient en production avec certaines applications, ils sont revenus, ils ont dit: «Je suis juste en train de stabiliser mon cluster Hadoop, en me stabilisant sur MapReduce YARN version 2, MapReduce version 2, et les gens disent que MapReduce est mort, Spark est la prochaine chose, et certaines personnes disent que Flink sera la prochaine chose, comment vais-je faire face à cela? "
Et ces défis sont devenus si évidents pour nous que nous avons investi dans cette optimisation dynamique que nous appelons exécution intelligente. Au moment de l'exécution, lorsque le travail, lorsque ce pipeline de données est soumis, en fonction du cluster, qu'il s'agisse de Spark, qu'il s'agisse de MapReduce ou d'un serveur autonome Linux, nous décidons comment exécuter ce travail, nativement dans notre moteur, dans le cadre de cela. Flux de données Hadoop ou Spark. Il n'y a pas de frais généraux car tout est fait grâce à cette optimisation dynamique que nous avons et tout est également fait parce que notre moteur est si nativement intégré en raison de nos contributions open-source. Est-ce que ça répond à votre question?
Eric Kavanagh: Oui, c'est bien. Et je veux poser une autre question là-bas, puis Dez, nous pourrons peut-être vous attirer vous et Robin. Je viens de recevoir un commentaire hilarant d'un de nos participants. Je vais le lire parce que c'est vraiment assez concis. Il écrit: "Il semble que dans l'histoire des choses CHAUDES" - vous comprenez? Comme l'IdO - "c'est que plus vous essayez de" simplifier "quelque chose de vraiment complexe, le plus souvent il semble plus simple de faire les choses, le plus de corde suspendue est fournie. Pensez à la requête de base de données, à l'explosion, au multi-threading, etc. »Pouvez-vous commenter ce paradoxe auquel il fait référence? Simplicité contre complexité, et qu'est-ce qui se passe vraiment sous les couvertures?
Tendü Yogurtçu: Bien sûr. Je pense que c'est un point très valable. Lorsque vous simplifiez les choses et faites ces optimisations, d'une certaine manière sous les couvertures, quelqu'un doit prendre la complexité de ce qui doit arriver, non? Si vous paralysez quelque chose ou si vous décidez comment exécuter un travail particulier par rapport au cadre informatique, il y a évidemment une partie du travail qui est poussée, que ce soit du côté de l'utilisateur, du codage des menus ou de l'optimisation du moteur. Il y a une partie de cela, en simplifiant l'expérience utilisateur, il y a un énorme avantage à pouvoir tirer parti des compétences qui existent dans l'entreprise.
Et vous pouvez en quelque sorte atténuer ce paradoxe, atténuer ce défi de «oui, mais je n'ai pas le contrôle de tout ce qui se passe sous le capot, sous le capot de ce moteur», en exposant les choses aux utilisateurs les plus avancés s'ils veulent avoir ce genre de contrôle. En investissant également dans certains types de choses de service. Être en mesure d'offrir des métadonnées plus opérationnelles, des données plus opérationnelles, comme dans l'exemple donné par ce participant, pour une requête SQL ainsi que le moteur en marche. J'espère que cela répond.
Eric Kavanagh: Oui, ça sonne bien. Dez, emportez-le.
Dez Blanchfield: Je suis vraiment désireux d'avoir un peu plus d'informations sur votre empreinte dans les contributions open source et le voyage que vous avez fait de votre expérience traditionnelle de longue date dans le mainframe et le monde propriétaire, puis le passage à contribuer à l'open source et comment cela s'est produit. Et l'autre chose que je tiens à comprendre, c'est le point de vue que vous voyez que les entreprises, pas seulement les services informatiques, mais les entreprises prennent maintenant en ce qui concerne les centres de données ou les lacs de données comme les gens le disent maintenant et s'ils voient cette tendance de juste un seul lac de données consolidé ou si nous voyons des lacs de données distribués et que les gens utilisent des outils pour les assembler?
Tendü Yogurtçu: Bien sûr. Pour le premier, ce fut un voyage très intéressant, en tant qu'éditeur de logiciels propriétaire, l'un des premiers après IBM. Cependant, encore une fois, tout a commencé avec nos clients évangélistes regardant Hadoop. Nous avions des sociétés de données comme ComScore, elles ont été l'une des premières à adopter Hadoop parce qu'elles collectaient des données numériques à travers le monde et n'étaient pas en mesure de conserver 90 jours de données à moins d'avoir investi une boîte d'entrepôt de données de dix millions de dollars dans leur environnement. Ils ont commencé à regarder Hadoop. Avec cela, nous avons également commencé à regarder Hadoop.
Et lorsque nous avons pris une décision et reconnu que Hadoop allait vraiment être la plate-forme de données du futur, nous avons également compris que nous ne pourrions pas avoir un jeu dans ce jeu, un jeu réussi dans ce domaine, à moins que nous faisaient partie de l'écosystème. Et nous travaillions en étroite collaboration avec les fournisseurs Hadoop, avec Cloudera, Hortonworks, MapR, etc. Nous avons commencé à vraiment discuter avec eux parce que le partenariat devient très important pour valider la valeur qu'un fournisseur peut apporter et s'assure également que nous pouvons aller ensemble dans l'entreprise. et offrir quelque chose de plus significatif. Cela nécessitait beaucoup de relations car nous n'étions pas connus des projets open source Apache, mais nous avons eu un grand soutien de ces fournisseurs Hadoop, je dois dire.
Nous avons commencé à travailler ensemble et à examiner le hub, comment nous pouvons apporter de la valeur sans même notre logiciel propriétaire dans l'espace. C'était important. Il ne s'agit pas seulement de mettre en place des API sur lesquelles votre produit peut fonctionner, c'est de pouvoir dire que j'y investirai car je pense qu'Hadoop va être une plateforme du futur, donc en investissant dans les sources que nous voulions faire sûr qu'il mûrit et devient prêt pour l'entreprise. Nous pouvons effectivement activer certains des cas d'utilisation qui n'étaient pas disponibles avant nos contributions. Cela profitera à l'ensemble de l'écosystème et nous pouvons développer ces partenariats de très près.
Cela a pris pas mal de temps. Nous avons commencé à contribuer en 2011 et 21 janvier 2013 - je me souviens de la date parce que cette date a été notre plus grande contribution engagée, ce qui signifie que nous pouvons maintenant avoir nos produits généralement disponibles à partir de ce moment - il a fallu un certain temps pour développer ces relations, montrent la valeur, les partenaires deviennent des partenaires de conception avec les fournisseurs et les committers de la communauté open-source. Mais c'était très amusant. En tant qu'entreprise, c'était très enrichissant pour nous de faire partie de cet écosystème et de développer un excellent partenariat.
La deuxième question sur le centre de données / lac de données, je pense que lorsque nous voyons ces données comme une implémentation de service dans la plupart des cas, oui, il peut s'agir de clusters, physiquement simples ou multiples, mais c'est plus conceptuel que de devenir ce seul endroit pour toutes les données. Parce que dans certaines organisations, nous voyons des déploiements de cluster importants sur site, mais ils ont également des clusters, par exemple, dans le cloud public, car certaines des données collectées à partir des sections en ligne sont vraiment conservées dans le cloud. Il est important d'avoir un pipeline de données unique que vous pouvez réellement exploiter ces deux, et les utiliser comme un hub de données unique, un lac de données unique, devient important. Pas nécessairement seulement l'endroit physique, mais avoir ce centre de données et ce lac de données entre les clusters, les géographies et peut-être sur site et dans le cloud va être très critique, je pense. Surtout pour aller de l'avant. Cette année, nous avons commencé à voir de plus en plus de déploiements cloud. C'est incroyable. Jusqu'à présent, le premier semestre de cette année a vu de nombreux déploiements dans le cloud.
Eric Kavanagh: D'accord, cool. Et Robin, avez-vous des questions? Je sais qu'il ne nous reste que quelques minutes.
Robin Bloor: D'accord, je peux lui poser une question. La première chose qui m'est venue à l'esprit est qu'il y a eu beaucoup d'enthousiasme à propos de Kafka et j'étais intéressé par votre opinion sur Kafka et comment vous vous intégrez à la façon dont les gens utilisent Kafka?
Tendü Yogurtçu: Bien sûr. Oui, Kafka devient très populaire. Parmi nos clients, nous voyons que c'est une sorte de couche de transport de données et nous considérons que les données sont un bus, à peu près. Par exemple, l'un de nos clients utilisait en fait une sorte de données consommatrices qui sont poussées dans ce Kafka parmi plusieurs, comme des milliers d'utilisateurs en ligne et pouvant les classer et les transmettre.
Encore une fois, Kafka est un bus de données pour les différents consommateurs de ces données. Classez certains utilisateurs avancés par rapport aux utilisateurs moins avancés et faites quelque chose de différent à l'avenir dans ce pipeline de données. Notre intégration à Kafka est fondamentalement, notre produit DMX-h devient un consommateur fiable, un consommateur très efficace et fiable pour Kafka. Il peut lire les données et ce n'est pas différent de la lecture de données à partir d'une autre source de données pour nous. Nous donnons aux utilisateurs la possibilité de contrôler la fenêtre en termes de temps requis ou de nombre de messages qu'ils peuvent consommer du bus Kafka. Et nous pouvons également enrichir ces données au fur et à mesure qu'elles traversent notre produit et sont repoussées dans Kafka. Nous l'avons testé. Nous l'avons comparé sur le site du client. Également certifié par Confluent. Nous travaillons en étroite collaboration avec les gars de Confluent et c'est très performant et facile à utiliser. Là encore, les API changent, mais vous n'avez pas à vous inquiéter car le produit le traite vraiment comme une autre source de données, une source de données en streaming. C'est assez amusant de travailler avec notre produit et Kafka, en fait.
Robin Bloor: D'accord, j'ai une autre question qui est juste une sorte de question commerciale générale, mais je connais Syncsort depuis longtemps et vous avez toujours eu la réputation et livré un logiciel extraordinairement rapide pour ETL et le monde du mainframe. Est-il vrai que la plupart de vos activités sont désormais transférées à Hadoop? Est-il vrai que d'une manière ou d'une autre, vous avez réparti votre entreprise de manière assez spectaculaire par rapport au monde des ordinateurs centraux?
Tendü Yogurtçu: Nos produits mainframe exploitent toujours 50% des mainframes dans le monde. Nous avons donc une gamme de produits mainframe très solide en plus de ce que nous faisons sur le big data et le Hadoop. Et nous sommes toujours dans la plupart des projets de simplification ou d'optimisation informatique, car il y a une extrémité que vous souhaitez pouvoir exploiter vos données mainframe dans les plates-formes Multex Big Data et exploiter toutes les données d'entreprise, mais il existe également des charges de travail transactionnelles très critiques. qui continue de fonctionner sur le mainframe et nous offrons à ces clients les moyens de vraiment rendre ces applications plus efficaces, exécutées dans le moteur zIIP afin qu'elles ne consomment pas autant de cycles de traitement et MIPS, les rendent rentables.
Nous continuons d'investir dans les produits mainframe et de jouer dans cet espace où les gens passent du gros fer mainframe au big data et couvrent également la gamme de produits sur ces plateformes. Donc, nous ne déplaçons pas nécessairement toute l'entreprise d'un côté, nous continuons à avoir des affaires très réussies des deux côtés. Et les acquisitions sont également une priorité pour nous. À mesure que cet espace de gestion et de traitement des données pour les plates-formes Big Data évolue, nous nous engageons également à effectuer quelques acquisitions complémentaires.
Robin Bloor: Eh bien, je suppose que je ne peux pas vous demander ce que c'est parce que vous ne seriez pas autorisé à me le dire. Je voudrais savoir si vous avez vu de nombreuses implémentations de Hadoop ou Spark sur le mainframe ou si c'est une chose très rare.
Tendü Yogurtçu: Nous n'en avons pas vu. Il y a plus de question là-dessus. Je pense que Hadoop sur l'ordinateur central n'avait pas beaucoup de sens en raison du type de structure de base. Cependant, Spark sur le mainframe est assez significatif et Spark est vraiment très bon avec le machine learning et l'analyse prédictive et pouvoir avoir certaines de ces applications avec des données mainframe est vraiment, je pense, assez significatif. Nous n'avons encore vu personne faire cela, mais c'est vraiment le cas d'utilisation qui conduit ces choses. Si votre cas d'utilisation en tant qu'entreprise apporte davantage ces données mainframe et s'intègre avec le reste des ensembles de données dans la plate-forme Big Data, c'est une histoire. Cela nécessite d'accéder aux données de l'ordinateur central à partir de la plate-forme Multex Big Data, car il est peu probable que vous apportiez vos ensembles de données à partir de systèmes ouverts et que vous les rappeliez sur l'ordinateur central. Cependant, si vous avez des données mainframe que vous souhaitez simplement explorer et faire un peu de découverte d'exploration de données, appliquez une IA avancée et des analyses avancées, alors Spark pourrait être un bon moyen d'aller et de fonctionner sur le mainframe comme ça.
Eric Kavanagh: Et voici une autre question du public, en fait deux autres. Je vais vous poser une question par équipe, puis nous terminerons. Un participant demande: «IBM intègre-t-il vos contributions open-source sur son écosystème de cloud public, en d'autres termes, le Bluemix?» Et un autre participant a fait valoir un très bon argument, notant que Syncsort est idéal pour garder le gros fer en vie pour ceux qui l'ont déjà, mais si les entreprises renoncent à de nouveaux mainframes en faveur de ce qu'il appelle CE, cloud tout, cela va probablement décliner, mais note que vous êtes vraiment bons pour déplacer des données en contournant les systèmes d'exploitation jusqu'à un gigaoctet par seconde. Pouvez-vous nous parler de votre force principale, comme il l'a mentionné, et si IBM intègre ou non vos produits dans Bluemix?
Tendü Yogurtçu: Avec IBM, nous sommes déjà partenaires d'IBM et nous avons eu des discussions pour leurs services de cloud de données offrant le produit. Nos contributions open-source sont ouvertes à tous ceux qui souhaitent en tirer parti. Une partie de la connectivité mainframe est également disponible dans les packages Spark, donc pas seulement IBM. Tout le monde peut en tirer parti. Dans le Bluemix, nous n'avons encore rien fait de spécifique à ce sujet. Et ça vous dérange de répéter la deuxième question?
Eric Kavanagh: Oui, la deuxième question concernait votre principal domaine de fonctionnalité au fil des ans, qui traitait vraiment les goulots d'étranglement d'ETL et, évidemment, c'est quelque chose que vous allez toujours faire en tant que mainframes, eh bien, théoriquement, restez à l'écart, bien que Dez le point est encore en train de basculer et de rouler là-bas. Mais le participant vient de noter que Syncsort est très bon pour déplacer des données en contournant les systèmes d'exploitation et jusqu'à un gigaoctet par seconde. Pouvez-vous simplement commenter cela?
Tendü Yogurtçu: Oui, l'efficacité vraiment globale des ressources a été notre force et l'évolutivité et la performance ont été notre force. Nous ne faisons pas de compromis, simplifier a de nombreuses significations, nous ne faisons aucun compromis à partir de celles-ci. Lorsque les gens ont commencé à parler de Hadoop en 2014, par exemple, de nombreuses organisations ne regardaient pas vraiment les performances au départ. Ils disaient: "Oh, si quelque chose se passe, je peux ajouter deux autres nœuds et ça ira, les performances ne sont pas mon exigence."
Alors que nous parlions d'avoir les meilleures performances parce que nous fonctionnions déjà en mode natif, nous n'avions même pas certains des hoquets initiaux que Hive avait avec plusieurs tâches MapReduce et les frais généraux avec leur démarrage. Les gens nous disaient: "Oh, ce n'est pas mon inquiétude, ne t'inquiète pas pour le moment."
Lorsque nous sommes arrivés en 2015, ce paysage a changé car certains de nos clients ont déjà dépassé le stockage qu'ils avaient dans leurs clusters de production. Il est devenu très important pour eux de voir ce que Syncsort peut offrir. Si vous prenez des données d'une base de données ou d'un ordinateur central et que vous écrivez dans un format Parquet dans les clusters, que vous atterrissiez et mettiez en scène et effectuiez une autre transformation ou que vous effectuiez simplement la transformation en vol et le format de fichier cible atterri, cela a fait une différence parce que vous enregistrez stockage, vous enregistrez à partir de la bande passante réseau, vous enregistrez à partir de la charge de travail sur le cluster car vous n'exécutez pas de travaux supplémentaires. Ces forces que nous jouons en termes de conscience, nous ressentons l'efficacité des ressources sous notre peau, semble-t-il.
Voilà comment nous le décrivons. C'est essentiel pour nous. Nous ne tenons pas cela pour acquis. Nous ne l'avons jamais pris pour acquis, nous continuerons donc d'être forts avec cet effet de levier dans Apache Spark ou la prochaine infrastructure informatique. Cela restera notre priorité. Et en termes de mouvement de données et d'accès aux données, c'est certainement l'une de nos forces et nous accédons aux données DB2 ou VSAM sur les mainframes dans le contexte de Hadoop ou Spark.
Eric Kavanagh: Eh bien, c'est un excellent moyen de mettre fin à la webémission, les amis. Merci beaucoup pour votre temps et votre attention. Merci à vous, Tendü et Syncsort, d'être venus dans la salle de briefing et d'être intervenus, comme on dit. Beaucoup de bonnes questions du public. C'est un environnement en constante évolution, les amis. Nous archiverons cette Hot Tech comme nous le faisons avec toutes les autres. Vous pouvez nous trouver sur insideanalysis.com et sur techopedia.com. Habituellement, il monte en une journée environ. Et avec cela, nous allons vous dire adieu, les amis. Merci beaucoup. Nous vous parlerons bientôt. Prends soin de toi. Bye Bye.
