Retours de Strata + Hadoop World 2016 - Partie 2
Ici, nous allons nous concentrer sur les autres technologies abordées pendant les sessions que nous avons suivies (Apache Nifi, Apache Drill, GPU, Hadoop Recordservice…), sur les sujets liées à la donnée (traitement du langage, data-driven business, partage de la donnée...), et nous terminons par quelques inclassables futuristes ou philosophiques (le futur de l’IA, le futur d’Hadoop, le relativisme des données…).
Liste des sessions :
The rise of the GPU: GPUs will change how you look at big data Simplifying Hadoop with RecordService, a secure and unified data access path for compute frameworks High-performance data flow with a GUI—and guts Analyzing dynamic JSON with Apache Drill Deep learning and natural language processing with Spark Applications of natural language understanding: Tools and technologies Beyond the hunch: Communicating uncertainty for effective data-driven business Using data for evil IV: The journey home Data wants to be shareable The Internet of Things: it’s the (sensor) data, stupid Data relativism and the rise of context services The future of (artificial) intelligence The next 10 years of Apache Hadoop
The rise of the GPU: GPUs will change how you look at big data
Todd Mostak (MapD)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49544
TL;DR : Introduction d'une base de données utilisant des GPUs pour répondre aux requêtes.
Todd Mostak, fondateur et CEO de MapD, nous présente leur base de données tirant profit des capacités des GPUs pour répondre à des requêtes de l'ordre du milliard de lignes en quelques millisecondes.
La première partie de sa présentation porte sur l'évolution de la vitesse de requêtage des bases de données au fur et à mesure du temps. Il rappelle que l’on a observé une accélération de 100x lors du passage du disque à la RAM CPU (RAM adressable par le CPU), puis 1000x lors de la transition de la RAM CPU vers la RAM GPU (RAM adressable par le GPU).
Les GPUs, en terme de performance, ont en effet évolué beaucoup plus rapidement que les CPUs, mais pas à coût équivalent. Les serveurs CPUs d'aujourd'hui peuvent avoir de l'ordre de quelques dizaines de coeurs quand les serveurs GPUs bénéficient d'environ 40000 coeurs pour du milieu de gamme. De même, la RAM GPU bénéficie d'une bande passante largement supérieure à la RAM CPU.
Mr Mostak fait état des derniers tests menés chez leurs clients et qui démontrent qu’à coût égal (€), un noeud équipé avec des GPUs permet d'avoir des performances 100x meilleures que 10 noeuds utilisant des bases in-memory (RAM CPU) lors du requêtage. Cela permet également d'éliminer des coûts de maintenance de 10 noeuds contre 1 noeud.
Sur la gestion du stockage de la donnée, il précise que seule la donnée la plus requêtée est stockée dans les GPUs, ce qui leur permet d'obtenir ces temps. Dans leur système, il apparente en terme de temps d’accès la GPU RAM à un cache L1, la CPU RAM à L2 et le disque à L3.
Leur base est actuellement réservée à l’analytique et ne supporte donc pas de transactionnel, mais la démonstration effectuée est impressionnante avec des milliards de lignes requêtées de manière répétitive via une carte interactive mise à jour en quelques dizaines de milisecondes.
Une technologie prometteuse qui a tout de même un coût de nos jours.
Simplifying Hadoop with RecordService, a secure and unified data access path for compute frameworks
Alex Leblang (Cloudera)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49480
TL;DR : Le RecordService est une couche logicielle située entre les services de traitement et les services de stockage de l'ecosystème Hadoop. Il permet d'éliminer des besoins comme les accès sécurisées à la donnée, l'audit, etc. pour les composants des distributions Hadoop.
Le speaker faisant partie de l'équipe de développement du RecordService, il nous détaille les fonctionnalités et l'intérêt de ce nouveau produit disponible sur la plateforme de Cloudera sous peu (GA sous 3 à 6 mois).
Le Record Service se place en tant que couche centrale à laquelle chaque framework de calcul s’adresse avant d’avoir accès à la donnée. Cette couche centrale a plusieurs rôles parmi ceux de fournir des informations d'accès à la donnée, de la sécurité et de l'audit.
Du côté architecture le RecordService comprend un ou plusieurs composants masters et des composants workers. Les workers sont déployés sur chaque noeud du cluster ce qui permet à chaque autre service de calcul (Spark, MapReduce, etc…) d’interagir en local avec le RecordService. La coordination du service dans son ensemble est géré par Zookeeper. L’outil s’intègre bien (pour la partie sécurité) avec Sentry qui, on le rappelle, dans la distribution Cloudera expose des métadonnées sur les permissions des utilisateurs relatives aux différents services du cluster.
Cet outil, sur son aspect sécurité, ressemble à Apache Ranger qui, lui, est plutôt mis en avant par Hortonworks. Il diffère cependant en terme d'architecture.
Pour plus d’informations, c’est ici.
High-performance data flow with a GUI—and guts
Simon Elliston Ball (Hortonworks)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49691
TL;DR : Démonstration de NiFi, produit au coeur de la HDF (Hortonworks Data Flow)
Simon Elliston Ball nous propose une session de démonstration des fonctionnalités d'Apache NiFi, produit développé initialement par la NSA il y a 9 ans, et aujourd'hui utilisé par Hortonworks dans leur plateforme HDF qui s'intègre directement à la HDP pour réaliser l'ingestion de donnée dans un datalake.
NiFi est principalement une interface graphique (GUI) avancée avec des boîboîtes que l'on click'n'drag puis que l’on connecte entre elles pour former un flux de données au fil de l'eau appelé dataflow. Ce flux de données peut comprendre plusieurs étapes, en fonction de ce que l’utilisateur définit, dont celles de lecture de la source et de stockage dans la cible, ainsi que certaines étapes de calcul. Un grand nombre d'options sont disponibles en terme de type de source de données, de système de stockage en bout de chaine et d'unité de traitement. Toutes sont personnalisables avec des options permettant de varier du batch à l’événément en passant par le micro-batch. L'unité de base s’appelle Flowfile qui est, malgré son nom, une unité atomique de donnée transmise dans le dataflow ; sa taille peut varier de 1 byte à plusieurs gigabytes.
Entre plusieurs étapes d'un flow de données, les Flowfiles sont stockées sur un broker propre à NiFi et qui fonctionne de manière semblable à Kafka. On notera finalement des similitudes avec des outils comme Kafka Streams ou Samza.
Le système génère également des métriques sur chaque étape par laquelle passe la donnée : ces métriques sont disponibles en temps réel directement dans l'UI.
L’autre partie importante de NiFi, et l’une des fonctionnalités les plus abouties (NSA oblige), est le système de provenance et tracking de la donnée. Toujours dans l'UI, il est possible de savoir à la seconde près où dans le dataflow se situait un certain évènement avec une visualisation graphique on ne peut plus explicite. Il est également possible de savoir qui a téléchargé la donnée. Toute action est donc suivie et il est possible de reconstituer les opérations et la provenance de la donnée. Ce système de tracking est quasiment aussi coûteux en terme de ressources que les traitements du dataflow.
NiFi se résume comme étant un système graphique efficace pour garder le contrôle de la donnée tout en ayant une flexibilité au niveau des traitements et des possibilités de source d’import. En conclusion du talk on apprend aussi que NiFi est disponible en version légère pour l'IoT avec un support sur des plateformes telles qu'Arduino.
Analyzing dynamic JSON with Apache Drill
Tomer Shiran (Dremio)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49757
TL;DR : Apache Drill permet de faire du SQL sur de nombreuses sources de données relationnelles ou non. Il utilise comme format de stockage interne celui proposé par Apache Arrow : un format orienté colonne en mémoire optimisé, qui vise à devenir un standard pour partager des données en mémoire entre produits de l’écosystème Big Data.
Tomer Shiran présente Apache Drill, un moteur SQL capable de s’interfacer avec de nombreuses solutions de stockage. Il permet de requêter n’importe laquelle de ces sources comme si c’était une base de donnée relationnelle. Il est donc possible de faire des jointures entre des bases de données complètement hétérogènes, en une seule requête SQL.
Certaines des bases de données compatibles avec Drill stockent leurs données au format JSON. Une requête SQL exécutée sur des formats JSON avec des schémas hiérarchiques hétérogènes et changeants peut être très peu performante. Pour rendre le stockage JSON rapide à analyser, Apache Drill utilise en interne le format proposé par le projet Apache Arrow. C’est un format haute performance orienté colonne en mémoire. Le format utilise des fonctionnalités CPU comme les opérations vectorisées, il permet d’accéder aux valeurs en temps constant, de faire des opérations directement sur les données compressées, et de représenter des données hiérarchiques et changeantes.
Le format d’Apache Arrow vise également à devenir un standard d’interopérabilité pour les produits Big Data. En effet, deux processus utilisant Arrow peuvent “relocaliser” la donnée d’un process à l’autre sans supporter les coûts de sérialisation et désérialisation habituels (elle représente, d’après Tomer Shiran, 80% du temps CPU impliqué dans la communication).
Apache Drill semble être une solution intéressante pour requêter des sources hétérogènes, et pourquoi pas remplacer un datalake pour les besoins simples de croisement de données. Les fondateurs de Dremio, dont l’activité précise n’a pas été évoquée, sont comitteurs principaux sur Apache Drill.
Deep learning and natural language processing with Spark
Andy Petrella (Data Fellas), Melanie Warrick (Skymind)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49620
TL;DR : Présentation d'une API permettant de distribuer des RNN (Recurrent Neural Network) de type LSTM (Long Short Term Memory) sur du Spark.
Andy Pretella (Data Fellas) et Melanie Barrick (Skymind) sont venus nous parler des applications du Deep Learning et du Natural Language Processing (NLP) de façon distribuée.
Une brève introduction revient sur les concepts clé du Deep Learning et de la NLP ainsi que la manière d’utiliser des algorithmes de Deep Learning pour faire du NLP.
Les algorithmes couramment utilisés pour la NLP sont des réseaux de neurones récurrents (RNN) de type Long Short Term Memory (LSTM). Les RNNs seraient particulièrement efficaces quand les données travaillées sont répétitives. Le type LSTM permet, lui, d'être plus efficace sur des analyses NLP, puisque sur du texte il permettra de retenir comment les mots sont mis bout à bout quand d'autres types d'algorithmes ne seraient, par exemple, capables de traiter un texte que mot par mot sans pouvoir associer un mot au contexte d'une phrase.
Le coeur du problème, là où sont intervenus nos deux speakers, est la scalabilité de tels algorithmes pour pouvoir traiter de grosses volumétries de données. Pour y répondre, ils ont ainsi créé des bibliothèques Java qui implémentent les algorithmes de datascience mentionnés ci-dessus et un connecteur Spark qui permet de les distribuer grâce à Spark.
On retrouve donc plusieurs bibliothèques dont celle de la couche d’accès à la donnée qui s’intitule Canova, DL4J qui implémente des algorithmes de Deep Learning en Java et ND4J (équivalent de NumPy en python) qui est une bibliothèque "utilitaire" d'algèbre linéaire.
Andy Pretella a par la suite fait une démo de l'utilisation de ces bibliothèques en effectuant de l’analyse de sentiments sur les données IMDB d'avis sur les films, avec pour but d'évaluer si une critique est positive ou négative. La création de features passe par l'utilisation de Word2Vec de Google avec environ 300 features générées pour chaque mot de l’avis IMDB. Ces features sont par la suite ingérées par les bibliothèques présentées ci-avant pour arriver à des résultats concluants.
En définitif, ils ont réussi via les bibliothèques mises en place à utiliser Spark pour scaler des algorithmes de machine learning codés en Java ou Scala, ainsi qu’à mettre à disposition du code pour faire des RNN, qui ne sont à ce jour pas implémentés les bibliothèques de type Spark MLLib.
Applications of natural language understanding: Tools and technologies
Alyona Medelyan (Entopix)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/50933
TL;DR : Alyona Medelyan évoque trois exemples de compréhension automatique du langage naturel (sous-ensemble du traitement automatique du langage naturel), et propose quatre conseils généraux à suivre dans ce domaine.
Le premier exemple proposé est la découverte de relations sémantiques entre concepts. Deux projets dans ce domaine sont évoqués : l’Open Information Extraction de l’université de Washington, qui permet d’extraire des concepts et des relations à partir de n’importe quel corpus textuel, et le projet ProBase de Microsoft Research qui contient une ontologie de presque trois millions de concepts. Le but ultime de ces projets, selon Alyona, est de dériver automatiquement de nouvelles connaissances à partir de ces représentations sémantiques du monde.
Le second exemple est celui de l’analyse de sentiments, une pratique bien connue qui consiste à analyser les mots d’un corpus de texte pour comprendre automatiquement le “sentiment” de ce corpus : est-ce un message positif, neutre, négatif ?
Les chat bots sont enfin évoqués, ces robots qui peuvent dialoguer avec les humains, comme celui de Microsoft (Cortana), le produit “wit.ai, ou bien sûr Siri d’Apple. Alona Medelyan remarque qu’il est amusant de voir que si les robots veulent se faire passer pour des humains, la technologie des chat bots est encore souvent imparfaite, et ce sont parfois encore de vrais humains qui se font passer pour des chat bots.
Quelques conseils en vrac ont ensuite été prodigués :
- Il existe beaucoup d’algorithmes de qualité open source pour le Natural Language Understanding (word2vec, stanfordNLP, gensim, chatterbat, maui, etc.), et, dans un premier temps, une solution commerciale a peu de chances d’être nécessaire. Elle devient intéressante si cette solution est spécialisée et entraînée sur votre domaine particulier.
- La connaissance métier est plus importante que le choix du meilleur algorithme. Alyona prend l’exemple d’une équipe de Salesforce qui a compris l’intérêt de pouvoir faire des requêtes en langage naturel sur Salesforce grâce à leur connaissance des besoins métier.
- Vous avez sans doute déjà assez de données pour construire un modèle de langage de votre métier. Pensez aux emails, aux forums, aux logs de chats ou de call center, au site web, etc.
- Le deep learning n’est pas toujours la solution. Beaucoup d’autres algorithmes peuvent être efficaces. Alyona recommande d’utiliser la ressource GitXiv.com qui contient un ensemble d’algorithmes joints avec des données, ce qui permet de tester des algorithmes sur des données particulières.
Les slides sont disponibles ici : http://cdn.oreillystatic.com/en/assets/1/event/155/Applications%20of%20natural%20language%20understanding_%20Tools%20and%20technologies%20Presentation.pdf
Beyond the hunch: Communicating uncertainty for effective data-driven business
Abigail Lebrecht (uswitch)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49459
TL;DR : Abigal Lebrecht millite pour une communication responsable de la donnée avec l’incertitude qui lui est associée. Elle propose un cadre de décisions “data-driven”, où les incertitudes des analyses de données sont communiquées, et où l’intuition liée à l’expérience est prise en compte.
Abigal Lebrecht se désole de deux constats : la donnée est parfois mal utilisée et elle n’est pas communiquée avec l’incertitude statistique qui y est associée. Nous devons être capables, à la fois dans les médias et dans les entreprises, de communiquer sur l’incertitude des analyses de données. Comment faire ?
Le Daily Express titre en Une : “92% veulent quitter l’UE”. Ce titre racoleur est en fait le résultat d’un sondage uniquement mené sur le site du Daily Express : il n’est bien sûr fait aucune mention du biais d’échantillonnage que ce recueil induit. De même, certains sondages sur Twitter omettent de mentionner le biais inhérent à la population utilisant Twitter.
Ce manque d’information sur la collecte et l’analyse s’observe également en entreprise. En général, les data scientists en entreprise analysent des données, et font une recommandation, sans communiquer sur la méthodologie et l’incertitude associée (biais d’échantillonage, intervalles de confiance, etc.). Si cette recommandation s’avère fausse, le management peut décider d’arrêter de travailler la donnée. Si elle s’avère être en contradiction avec l’intuition du métier, il peut être difficile de trancher entre donnée et intuition basée sur l’expérience.
Or, aucun résultat statistique unique ne peut se substituer à un raisonnement scientifique : les résultats doivent être basés sur un design expérimental valide, une variété d’indicateurs sur la donnée, une interprétation enracinée dans un contexte.
Abigail suggère donc d’éviter autant que possible les approches fréquentistes qui aboutissent à un résultat unique dans un intervalle de confiance difficile à expliquer, et d’adopter plutôt une approche bayésienne.
Cette approche, basée sur le théorème de Bayes, permet d’obtenir une probabilité, et permet d’inclure l’intuition du management ou des métiers via le terme “probabilité a priori” de la formule. Par exemple, sur un test A/B pour choisir la couleur d’un bouton sur un site web, une bonne intuition permettra de converger plus rapidement (avec moins de tests) vers une certitude forte du bouton à choisir. Au contraire, une mauvaise intuition augmentera le nombre de tests nécessaires. Ce cadre permet à la fois d’intégrer l’intuition, et de communiquer sur une probabilité pour sensibiliser les métiers au degré d’incertitude de l’expérience.
C’est une approche intéressante, même si une personne dans l’audience fait remarquer que communiquer une probabilité aux métiers est sans doute encore plus difficile que de communiquer un résultat ferme. Que faire quand sommes sûrs à 65% qu’il faut choisir le bouton rouge ?
Using data for evil IV: The journey home
Duncan Ross (TES Global), Francine Bennett (Mastodon C)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49658
TL;DR : les modèles basés sur les données représentent la réalité et peuvent être utilisés de manière bénéfique ou maléfique. Le refus sans discernement de l’utilisation des données peut également constituer une utilisation maléfique de ces données.
Cette session est la quatrième d’une série humoristique mais sérieuse sur notre capacité à faire du mal avec des données. “Parce que nous avons tous la capacité de rendre le monde un peu plus mauvais”.
En tant que data scientist, il est facile de faire quelque chose de mauvais de manière accidentelle. Deux sujets ont été abordés pendant cette session : comment les algorithmes peuvent devenir mauvais, et comment des incertitudes sur la data science peuvent amener à rejeter complètement et sans discernement l’utilisation des données.
Comment un algorithme peut-il être utilisé de manière mauvaise ? Imaginons un modèle linéaire simple qui rende compte des salaires sur le marché de l’emploi. Les variables explicatives de ce modèle sont par exemple le nombre d’années d’étude, le secteur d’activité, ou le genre. Il s’avère que la variable “genre” est significative : dans ce modèle, une femme gagne en moyenne 8000 euros de moins qu’un homme. Si l’on utilise ce modèle pour faire évoluer les mentalités sur les inégalités de salaire, on peut considérer que l’on fait le bien. En revanche, est-ce qu’un employeur qui utilise ce modèle pour déterminer un salaire, et qui entretient donc cette inégalité, est moralement fautif, ou est-ce qu’il s’aligne simplement sur la réalité du marché? La salle juge que c’est un comportement neutre, ni bon ni mauvais. Nous comprenons que l’algorithme n’est pas mauvais en soi : il capture ce que dit la donnée sur le monde réel. C’est ensuite à nous de décider comment l’utiliser, en bien ou en mal.
L’exemple d’une association humanitaire a été utilisée pour illustrer le second point : le refus sans discernement de l’utilisation des données. Cette association humanitaire pourrait faire 10% d’économies en optimisant son activité grâce à l’analyse de ses données, mais un de ses responsables s’inquiète de l’utilisation des algorithmes. Il décide alors de refuser complètement toute analyse de données. C’est une pratique qui est perçue par les présentateurs comme particulièrement cynique, et mauvaise.
Nous ne ressortons pas de cette session avec l’impression d’un propos très dense, mais ces exemples constituent tout de même une invitation à la réflexion et à la responsabilité.
Data wants to be shareable
Mona Vernon (Thomson Reuters Labs)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/53798
TL;DR : Mona Vernon présente plusieurs principes techniques et culturels pour rendre les données partageables dans un architecture “datalake”.
Mona Vernon, évoquant l’anecdote originelle de Reuters transférant des informations par pigeon voyageur avant l’invention du télégraphe, affirme la volonté de son entreprise de rendre l’information disponible toujours plus rapidement et complètement.
Elle aborde en particulier cette question dans le contexte d’un datalake : comment faire pour que l’information dans un datalake soit partageable et partagée ? Trois principes sont évoqués : communiquer le sens des données, décrire la provenance de la donnée, et gérer les droits d’accès et d’usage de la donnée. Dans ce but, Reuters a créé un outil de catalogage : Eikon.
Les outils ne font pas tout : Mona Vernon souligne également l’importance de créer des standards communs, de créer une culture ouverte et collaborative, de rendre la donnée partageable par défaut, et d’encourager et récompenser l’expérimentation.
Par analogie au NoSQL (Not Only SQL), Mona Vernon parle de la donnée comme étant NoDev (Not Only Developers) : c’est donc l’affaire de l’organisation dans son ensemble.
The Internet of Things: it’s the (sensor) data, stupid
Martin Willcox (Teradata)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/52348
TL;DR : les capteurs mentent, et ne se suffisent pas à eux-mêmes.
Les capteurs sont au coeur de l’Internet des objets, et Martin Willcox nous rappelle la nécessité de ne pas croire à la véracité des informations qu’ils renvoient. Les capteurs sont sensibles, et un capteur isolé peut “mentir” sur les données qu’il capte.
Un capteur seul n’apporte pas de sens : il faut d’une part être capable d’analyser des données de réseaux de capteurs pour avoir une représentation correcte de la réalité, et d’autre part lier ces données de capteur à des données externes pour en tirer de la valeur (données RH, données logistiques, etc.).
Data relativism and the rise of context services
Joe Hellerstein (UC Berkeley)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/51466
TL;DR : Une parabole épique en faveur du relativisme des données.
Joe Hellerstein formule une parabole évoquant trois archétypes qui embarquent pour un voyage épique en quête de la vérité et de l’unicité de la donnée.
Le département IT est symbolisé par le chevalier : il croit à l’existence de la vérité et recherche la source unique de la vérité (single source of truth). C’est un idéaliste. Le data scientist est un guerrier : il utilise la donnée et créé un modèle. Si celui-ci fonctionne, alors son but est atteint. La vérité n’existe peut être pas, et cela n’est pas un problème : c’est un sceptique. Le management, enfin, est la reine : elle cherche à gouverner et à conquérir.
Ces trois archétypes ont des conceptions philosophiques différentes de la réalité. La solution prônée par Joe est le relativisme des données. La vérité n’a alors d’existence que dans un contexte précis. Le management peut avoir besoin d’atteindre la vérité ou l’unicité, mais seulement dans un contexte donné : par exemple un besoin de rapprochement de sa base utilisateur avec des comptes Twitter. Ainsi, l’unicité peut être atteinte dans ce contexte, sans l’être dans l’ensemble du SI.
The future of (artificial) intelligence
Stuart Russel (UC Berkeley)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/50793
TL;DR : Stuart Russel évoque des pistes pour une intelligence artificielle bénéfique aux humains.
Stuart Russel évoque, dans un contexte futur d’omniprésence des robots, la manière dont nous pourrions créer des machines qui adoptent des comportements compatibles avec l’humanité.
Le premier principe esquissé est la nécessité de pouvoir agir sur le système une fois celui-ci mis en place. Stuart rappelle l’exemple du roi Midas qui souhaite que tout ce qu’il touche se transforme en or, et qui ne peut plus faire demi tour après avoir réalisé qu’il en mourrait. D’autre part, un robot intelligent ne devra pas être programmé pour optimiser un objectif simple, mais pour se comporter d’une manière qui soit satisfaisante pour les humains ; par exemple, un robot destiné à nourrir une famille devrait comprendre que tuer le chat n’est pas une solution satisfaisante.
Le robot doit donc avoir pouvoir objectif de maximiser la réalisation des valeurs humaines, mais il doit être incertain sur ces valeurs. La meilleure source d’information pour acquérir ces valeurs est d’observer les Hommes, mais la machine doit être programmée pour accepter d’engager une conversation et se corriger si nécessaire. Ces données d’apprentissage pourraient éventuellement être partagées mondialement, entre tous les robots. Enfin, principe primordial, le robot doit accepter d’être éteint.
The next 10 years of Apache Hadoop
Doug Cutting (Cloudera), Tom White (Cloudera), Ben Lorica (O’Reilly Media)
http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/50751
TL;DR : Tom White et Doug Cutting reviennent sur les dix ans d’Hadoop et proposent quelques prédictions pour le Big Data dans les 10 ans à venir. L’entretien a été peu dense mais quelques points intéressants en sont ressortis.
L’entretien entre le créateur d’Hadoop Doug Cutting et l’auteur du livre “Hadoop: The definitive guide” débute par des questions sur le chemin parcouru par Hadoop pendant ces dix dernières années. Doug Cutting révèle que le projet a pris beaucoup plus d’ampleur que ce qu’il imaginait initialement. Sans vouloir réécrire le passé, il s’interroge sur le choix de Java : aujourd’hui, il n’aurait peut être pas utilisé Java pour Hadoop, mais c’est peut être aussi ce choix qui l’a rendu si populaire. Aujourd’hui, il est “reviewer” sur le projet, et essaie constamment de se rendre dispensable.
Interrogé sur l’avenir du Big Data dans les 10 ans à venir, Tom White prédit que la facilité d’accès aux outils va se renforcer, avec le développement de notebooks et d’IDE spécialisés pour le Big Data. Doug Cutting ose quelques prédictions plus engagées :
- la consolidation des produits tant rêvée n’arrivera pas : l’environnement restera hétérogène et les développeurs continueront de choisir les briques nécessaires à leurs projets
- le Big Data sera la norme et le qualificatif “Big” n’aura plus lieu d’être
- les bases de données relationnelles vont s’éteindre, devenir ce que le COBOL est aujourd’hui aux langages de programmation.
- les outils pour gérer l’architecture Kappa vont se développer, pour faciliter le traitement conjoint des tâches batch et streaming (Apache Kudu est ici évoqué).
- sur Hadoop en particulier, un besoin important et auquel il faudra répondre rapidement est celui de la réplication multi datacenter.
Au contraire, quelles tendances ne vont pas durer ? Tom White évoque la “hype” de certains langages (“aren’t you all coding in Rust ?”) qui ne survivront peut être pas tous. Doug Cutting pense que l’intelligence artificielle est surestimée : même si beaucoup de progrès ont été faits dans la reconnaissance d’image par exemple, les techniques utilisées datent des années 1980, et il ne croit pas à de nouvelles améliorations dramatiques de l’IA.
Ce deuxième et dernier article arrive à son terme. Ce fut une année riche et nous espérons que ce brossage express vous aura donné envie de creuser ces sujets. A l’année prochaine !