Bon, on va commencer par le plus important. Je le fais maintenant parce qu'après vous ferez la gueule. bonsoir bonsoir à tout le monde vous m'entendez bien tout va bien ok super je suis ravi de voir une salle pleine il y avait une liste d'attente pour le meet up effectivement je vois que ça s'est bien rempli donc voilà moi c'est julien je suis évangéliste technique chez aws j'insiste sur technique mon rôle c'est faire exactement ce que je fais ce soir c'est à dire de prendre l'avion le train et de venir parler de venir parler aux développeurs de venir parler à la communauté technique française et au delà ceux qui me suivent sur twitter se demandent comment je peux voyager aussi vite proche de la vitesse de la lumière entre paris stockholm berlin etc bon mais j'y arrive en tout cas ce soir je suis en france je suis à Toulouse Je suis très content d'être là et merci encore à TDS pour l'invitation. Ça faisait longtemps que j'attendais ça. Alors ce soir on a un programme ultra chargé puisqu'il s'est passé plein de choses depuis 24 heures. En fait j'avais une démo tranquille, prête depuis des lustres que j'ai eu l'occasion de faire chez vos collègues lyonnais. Et puis il s'est passé deux choses. Ce matin en me levant en fait, tôt, j'ai vu qu'Amazon avait open sourcé sa librairie de deep learning qui s'appelle DSSTNE. J'ai compris ensuite qu'ils appellent ça Destiny. Je me suis dit que je ne pouvais pas décemment venir ici et ne pas en parler. Je voulais être le premier à en parler. Je pense que c'est la première présentation publique de Destiny, sincèrement. Le commit sur GitHub a été fait vers l'heure du matin en français. Ça m'étonnerait que quelqu'un m'ait battu. C'est une grande première, vous avez de la chance. On va voir si ça se passe bien. Et puis, il s'est passé une deuxième chose. En arrivant au bureau, j'étais tout excité par ça. Et je me suis rendu compte que j'avais un mail sympa qui me donnait enfin accès à Amazon QuickSight, qui est l'outil de BI d'Amazon, qui est encore en preview, mais que je vais enfin pouvoir montrer dans les mi-tés. De Redshift à Machine Learning, on est passé à Redshift, QuickSight, Machine Learning et Destiny. On va essayer de faire tout ça en une heure et quart. Je ne vous promets pas, mais on va essayer. Donc, quatre sujets à peu près dans l'ordre. Un sujet Data Warehouse, traditionnel dans l'approche, mais assez étonnant, assez surprenant dans son niveau de performance et son coût. On va commencer par ça. Ensuite, une fois qu'on aura des données dans Redshift et qu'on aura fait un peu de SQL, on essaiera d'y accéder avec QuickSight. Vous allez voir comment ce truc marche, c'est assez sympa. Une fois de plus, vous m'excuserez, la démo n'est pas hyper rodée parce qu'elle date de ce matin 11 heures à peu près, mais on va y arriver. Ensuite, on passera dans le monde de la prédiction avec Amazon Machine Learning. On utilisera des données qui sont dans Redshift pour construire un modèle. Et puis on finira en beauté, j'espère, avec Destiny sur une démo séparée que vous pourrez reproduire. C'est l'exemple qui a été touché aussi cette nuit sur GitHub donc un exemple de construction d'un modèle de recommandation pour des films, le grand classique, à partir d'un dataset assez volumineux. Et on fera ça avec des instances GPU tant qu'il fait. Voilà donc un gros programme, donc si vous avez des questions, allez-y. Si je sens que le timing est un peu serré, je garderai les questions pour les pizzas et la bière. Puis il vaut mieux que j'aie les manger et les bu, on y répond pas, ou pas. Alors juste la data AWS en 30 secondes, donc ça c'est la façon dont nos clients conçoivent le Big Data en général. Donc quatre phases assez traditionnelles, une phase de collect où on va récupérer des données qui proviennent d'une multitude de sources, qui peuvent aller de données web transactionnelles classiques à des logs web, qui est un grand classique du big data, à même des données IoT venant de device, bref, des sources très différentes avec des granularités très différentes, qui vont être stockées dans tout un ensemble de technologies, puisqu'on a tendance à penser qu'il n'y a pas de couteau suisse ultime qui permet de stocker et d'analyser toutes les données du big data. Donc on est obligé d'adapter et d'adopter des technos qui correspondent bien à ce qu'on est en train de faire. Donc pour aller aux deux extrêmes, si on est en train pour récupérer des données IoT, on va peut-être les mettre dans une base NoSQL comme DynamoDB, ou DonKinesis, ou Fils de messages. Et puis si on fait du transactionnel plus classique, on peut utiliser des systèmes comme RDS qui supportent MySQL, Postgre, etc. ensuite il va falloir les analyser donc là je dirais c'est pareil en fonction de ce que vous êtes en train de faire est ce que c'est un stream est ce que c'est du batch est ce que vous voulez faire de l'interactif on a une palette de techno donc nous aujourd'hui on va se concentrer vraiment sur le haut de la pile où on essaie de faire de l'analyse interactive de données on essaie de faire un peu de temps réel donc on parlera pas de la doup particulièrement ce soir Et puis enfin une phase de visualisation où là on va trouver tous les outils de la terre avec lesquels on est compatible. D'ailleurs il y en a une grande partie qui sont disponibles sur la marketplace d'AWS, donc vous pouvez lancer des instances, micro-stratégies etc. si ça vous amuse. Et on va parler enfin de QuickSight, auquel j'ai accès et je vais pouvoir vous montrer cette première version d'un outil de BI à l'assos AWS. On ne parle que du haut là, mais je pourrais revenir 10 fois et vous saouler avec tout le reste. Ce n'est pas l'objectif. Mais bon, si vous avez des questions sur ces trucs là tout à l'heure, on peut en discuter. Est-ce qu'il y a des gens qui sont clients à AWS dans la salle ? Oui ? 2, 3 ? Ok, c'est bien. Merci. Merci beaucoup. Ok, alors commençons par Redshift. Donc on va aller directement dans le gif du sujet. L'objectif de Redshift, c'est de fournir une alternative au data warehouse traditionnel, que je vais m'efforcer de ne pas citer parce que ce n'est pas la peine d'être désagréable, et je préfère parler de nos produits et de nos clients plutôt que les autres. Mais les gens qui ont une expérience de data warehouse dans la salle, je suis sûr qu'il y en a. Généralement les mots qui reviennent c'est compliqué, cher, pénible, ça marche pas toujours, on arrive le matin ça va pas tourner pendant la nuit etc. Et je parle d'expérience, je m'inclus dans ça. Et donc l'objectif de Redshift c'est de fournir une alternative qui soit simple, très scalable et très efficace économiquement Et donc le point le plus important c'est simple. Moi j'aime pas les choses compliquées sans doute parce que je les comprends pas. Et Redshift me plaît beaucoup parce que avant tout c'est un data warehouse qui est compatible avec Postgre. Donc une ancienne version de Postgre puisqu'on doit encore être compatible avec la 8 quelque chose. Bon ça sera gradé en temps et en temps. mais pour l'instant c'est encore un peu plus simple. Ce qui veut dire que tout va se faire en SQL et c'est tout. Pour contraster ça, c'est-à-dire que s'il y a des gens qui ont fait du Hive dans la salle ou qui en font encore, je ne sais pas s'ils ont aimé ça ou pas, personnellement ça ne m'a pas plu parce que le premier truc qu'il a fallu que je fasse c'est que je réapprenne HiveQL et ce n'était pas un grand moment de satisfaction. Là, on va pouvoir créer un Data Warehouse et l'interroger tout de suite, charger des données tout de suite en utilisant des commandes que vous connaissez déjà. Je pars du principe que tout le monde connaît SQL dans la salle, je me trompe peut-être. En tout cas, c'est un langage qui est hyper répandu. Le deuxième point, c'est que tous vos outils vont fonctionner parce qu'on a des drivers ODBC et JDBC pour Redshift. Donc, il n'y a pas de connecteur particulier, il n'y a pas de complication. vos outils de développement, vos dashboards, tous vos logiciels vont fonctionner directement avec Redshift. Il n'y a pas de plomberie particulière. Le deuxième point important, c'est scalable, rapide. Pourquoi ? Parce que c'est une architecture qui est parallèle. Vous allez le voir, on crée des clusters de nœuds qui vont travailler en parallèle sur les requêtes. Et puis comme c'est un service managé, vous n'avez aucune solution. d'administration système effectué. S'il y a des OBS dans la salle qui sont responsables de la solution X, Y ou Z fait par un grand constructeur, ils savent que c'est du boulot. Que les charges de monts de données, c'est du boulot. Que les serveurs qui tombent en panne, c'est du boulot. Que les jobs qui n'ont pas tourné la nuit, c'est du boulot. Etc, etc. Et je ne parle pas du coup. Donc il n'y a pas d'administration système. Vous créez le cluster, les instances sont gérées pour vous. vous avez votre chaîne de connexion, je vais vous montrer tout à l'heure, vous tapez dessus et c'est fini. Il n'y a pas d'obs à faire sur Word.chip. Si vous voulez le tester, vous avez un niveau d'usage gratuit comme sur beaucoup de services AWS. Vous pouvez utiliser 750 heures d'instance par mois pendant deux mois. Ça permet de faire un gros pop largement. Même si vous en servez 8 heures par jour vous mettez on va dire trois ou quatre nœuds, huit heures par jour ça fait on va dire 32 heures. Il y a moyen de jouer pendant un mois avec un vrai cluster tous les jours et de faire des trucs. Et au delà, alors les différents types de nœuds, le plus petit qui est celui que j'ai utilisé ce soir, il commence à je crois c'est 0,25$ de l'heure par nœud. C'est la région US, je crois qu'en Europe c'est 0,30 pour être précis. Ça veut dire que si vous créez un classique 4 nœuds, qui est déjà bien, il va vous coûter à peu près 1 dollar de l'heure. Vous l'éteignez la nuit quand vous n'en avez pas besoin et vous le relancez le matin. Et donc en optimisant un peu tout ça, je vous passe les calculs, on arrive à un coût de 1000 dollars par terabyte par an. Alors ça vous parle peut-être pas, c'est peut-être pas vous qui signez les chèques, mais Et si vous avez un data warehouse classique, regardez combien il coûte, regardez combien il y a de données dedans, vous allez voir que les chiffres sont bien plus élevés que ça. J'insiste pas trop sur les questions de prix parce que c'est souvent ce qui amène les gens sur Redshift, ils en peuvent plus de payer, de faire des gros chèques à x, y et z pour un niveau de satisfaction plutôt faible. Donc généralement ils veulent avant tout arrêter de payer cher pour un truc qui ne marche pas très bien. qui sont contents de trouver Redshift. Néanmoins, ce qui est important sur Redshift, c'est la perf. D'où ce slogan magnifique « Come for the cost, stay for the performance ». L'architecture, je ne rentre pas trop dans les détails parce que vous pourrez potasser tout ça dans la doc et puis évidemment, vous verrez les slides. Ce qui est important à retenir, c'est qu'il y a un nœud maître sur lequel on va se connecter, qui va recevoir les requêtes, qui va les compiler et qui va les partager entre les nœuds de calcul qui seront bas, qu'on appelle les compute nodes, qui sont les nœuds qui contiennent les données. Il y a un sharding qui va être fait au chargement des données sur ces différents nœuds et le nœud maître va splitter les requêtes, les envoyer au nœud, chaque nœud va travailler localement et va retourner son résultat. Donc architecture parallèle, c'est classique. Alors, juste pour vous donner un ou deux exemples de personnes qui utilisent ça, donc j'ai un premier case study qui est celui du Financial Times, que tout le monde connaît. Donc le Financial Times, leur truc, c'est de voir en temps réel ce que les gens lisent sur leurs différents sites web. Et en fonction de ça, de creuser tel ou tel article, de creuser telle ou telle histoire, parce qu'ils voient que c'est populaire. Donc ils avaient une stack fait par un autre vendeur, et puis il est arrivé le moment où ça ne marchait plus très bien et l'objectif, comme ils disent dans leur témoignage, ce n'est pas de savoir ce que les gens lisaient il y a trois jours, c'est de savoir ce que les gens lisent tout de suite. Donc si on a une solution d'analytics qui n'est pas tant réelle, elle ne satisfait pas ce besoin. Ils ont fait un pop sur Redshift qui a été monté très vite. Et pour la petite histoire, et je vous assure que c'est vrai, les requêtes du POC répondaient tellement vite que les gens du FT pensaient que ça ne marchait pas. C'est vrai, on a tous eu ce problème là où on balançait une requête et puis elle répond en 200 millégements dernier. Non. C'est impossible. Sauf que là, si. Voilà. C'est malheureux que il s'était habitué à des requêtes tellement lentes que là d'avoir un système qui répondait très vite ça les surprenait donc il a fallu que l'équipe technique d'AWS aille les voir et les convaincre que oui oui c'était le bon résultat et que oui oui c'était rapide. Et donc ils ont réussi à avoir une accélération de 90 à 98% sur certaines requêtes donc il faut bien voir si ça veut dire, je suis pas très bon en maths mais 98% c'est à dire que une requête qui durait 100 secondes, elle dure 2 secondes. On est d'accord, il y a des maths dans la salle. Il y a des mecs avec des doctorats, etc. Vous me corrigez si je dis désarri. N'hésitez pas, j'en dis souvent. Donc ça veut dire que c'est 50 fois plus rapide. Donc une requête qui durait peut-être 50 minutes, maintenant elle dure une minute. Donc effectivement, on peut imaginer que les gars étaient un peu surpris. Et donc maintenant, ils ont une solution qui est quasi temps réel et qui leur permet de scaler très très loin. Et ah oui j'avais dit que je parlerais pas trop du fric mais au passage ils ont divisé le coût total de la solution par quatre ce qui est appréciable. Ce qui n'est pas beaucoup pour Redshift. Il y a un deuxième exemple qui est Boeing Go. Alors si vous voyagez beaucoup, vous voulez vous les connaissez sans les connaître c'est le leader mondial des hotspots d'aéroports donc je les utilise beaucoup et donc ils ont un million de hotspots et donc pas mal de data et puis pas mal de croissance et l'objectif pour eux c'est toujours pareil c'est de faire de l'analytics c'est de faire du traitement de données donc une plateforme historique dont ils n'étaient pas satisfaits c'est toujours la ritournelle un peu sur les data ware Eux ils ont testé trois produits dont Redshift, ils ont choisi Redshift et ils ont fait la migration en deux mois. Alors qu'ils évaluaient que pour les autres solutions ça prendrait au moins quatre mois. Et donc ça c'est issu de leur présentation, ça c'est pas mes graphes, c'est les graphes du GP de Bongo qui est venu témoigner à notre conférence. Vous avez l'IRL de la vidéo complète qui est très intéressante, je vous la conseille. Et donc ça c'est en fait leur estimation. C'est à dire quand ils ont fait l'avant projet, ils se sont dit voilà Redshift ça va nous coûter 6 à 7 fois moins cher. Il s'avère que ça leur a coûté encore moins cher que ça. Parce que comme Redshift intègre de la compression automatique de données, en fait on a besoin de provisionner moins de nœuds pour stocker les données. Donc ils se sont retrouvés à finalement économiser encore plus que ça. Ils étaient contents. Et ça, c'est les pertes. Donc là, ils sont très contents. Et ces chiffres-là, ils paraissent incroyables. Le schéma est un peu petit. À droite, c'est le chargement de données. Donc, ils chargent, je crois, un an de données. Ah non, pardon, là, c'est un million de lignes. Donc là, ils chargent un million de lignes. Et ils passent de 7200 secondes à 7200 secondes. je crois 15 secondes je vous laisse calculer le speed up et sur les requêtes donc là pour un an de données il passe de 2700 secondes à 15 secondes bizarrement c'est le même chiffre donc on a des multiples d'accélération qui sont phénoménaux et un coût qui est là je crois que c'est 50 de mémoire c'est 50 000 dollars je crois que c'est ça 50 mille et là c'est 300 ou 400. Si ça 7 fois moins cher et on va dire 100 fois, 200 fois plus rapide pour leur use rate. Donc assez sympa. Et en fait on peut se demander comment c'est possible. Et moi c'est vrai que quand j'ai vu ces chiffres là je me dis c'est bizarre, ça paraît extraterrestre. En fait ce qui est agréable dans Redshift c'est qu'il n'y a pas de sorcellerie à faire pour obtenir des perfs. S'il y a des gens qui sont des bains dans la salle qui ont une activité de DBA sur des systèmes commerciaux. Vous savez qu'il y a énormément de boulot à faire et on peut tweaker très très loin. Je vais vous parler de ce que je connais un peu, Oracle par exemple. Un bon DBA Oracle est capable d'obtenir de la perte de sa base de données, de très haute perte, mais ça va être compliqué. Il va y avoir beaucoup de travail et beaucoup d'optimisation plus ou moins exotérée. sur Redshift il n'y a pas d'index, il n'y a pas de partitionnement, il n'y a pas de truc obscur. Il y a deux paramètres à régler. Il y a la taille des nœuds, oui on peut choisir parmi différentes tailles de nœuds, ça c'est sûr, mais il y a surtout deux paramètres, c'est la clé de distribution, c'est en gros la clé de sharding qui dit comment vous allez répartir les données entre les différents nœuds, il y a différentes politiques pour le faire. je ne rentre pas trop dans les détails parce que je n'ai pas vraiment le temps et il y a une clé de tri qui va dicter comment les données sont triées sur disque. Si vous faites par exemple beaucoup de order by sur une colonne, ça vaut peut-être la peine que les données soient triées sur disque en fonction de cette colonne. Ça vous permettra d'avoir directement les données triées en bon ordre et de ne pas refaire travailler les deux. Donc là aussi il y a de la littérature sur ces deux sujets là, si vous voulez jouer avec Redshift, le seul point que vous devez retenir à ce stade c'est que ces deux clés là sont cruciales pour la perte. Pour jouer avec des petits datasets, il n'y a pas de problème, quand vous passez à l'échelle, il faut vraiment que vous soyez posé la question de comment vous charlez les données et comment vous les triez. Sinon vous aurez des pertes décevantes et c'est comme ça qu'on peut avoir des speed-up monstrueux, c'est en shardant proprement et en triant les données. Donc les group by et les order by, ils vont pas mal dicter ce genre de choses. Donc voilà, il faut creuser ce point. Alors c'est bien d'en parler, on va commencer à le regarder. Donc là j'ai créé un cluster de ça. J'ai écrit un cluster. Vous arrivez encore à lire au fond ou c'est juste ? Un peu juste ? Ça va là ? C'est parce que sinon je vais devoir me balader en permanence avec le... Je peux peut-être cacher ça tant qu'il va faire. Ça va là ? Ouais. Donc j'ai créé un cluster de 16 nœuds. Alors je ne vous montre pas comment créer un cluster parce que c'est clic clic clic clic. Voilà. C'est tout. Ça n'a aucun intérêt. Vous n'avez pas besoin de moi pour savoir faire ça. Donc vous dites quelle taille de nœuds vous voulez. Donc là j'ai pris les plus petits. Ils s'appellent large. C'est comme ça. J'en ai mis 16. je me suis pourquoi pas à 37 de l'heure donc ça ça va me coûter alors il ya le master note qu'on paye pas 15 donc ça c'est 4 dollars 50 de l'heure ok donc là j'ai 16 nœuds je peux juste vous montrer quand même la console rapidement voilà il a été créé ce matin yuppie qu'est ce qu'on voit là pour l'aïdor rien faire donc les graves de performance et de CPU ça ne va pas nous aider beaucoup. Ce qui est plus sympa c'est qu'on peut voir toutes les requêtes qui ont été exécutées sur le cluster, on peut voir le plan d'exécution, ça pour le tuning c'est assez sympa. On peut voir les chargements de données qui ont été faits, combien de temps ils ont duré etc etc. J'ai fait mon gros chargement de données tout à l'heure, j'ai chargé un milliard de lignes en 10 minutes. Et c'est lent, c'est parce que c'est des petits nœuds qui ont peu d'IO, mais si j'avais pris des nœuds plus puissants, j'aurais pu le faire en une ou deux minutes, sans problème. Donc je vais me connecter dessus. Ok, voilà. Donc on est d'accord c'est du SQL ? On en confirme ? Donc j'ai créé une table. Alors les données c'est les données e-commerce d'Amazon que j'ai volé. Donc je pense qu'il y a les autres. Donc je sais qui a acheté des bêtises sur Amazonir. Voilà j'ai le nom, le prénom, le sexe, l'état, l'âge, je ne sais même à quelle heure vous l'avez acheté, combien vous avez dépensé etc. évidemment non. Donc c'est des données que j'ai générées pour ressembler à des données d'e-commerce parce que c'est souvent quelque chose qu'on a envie de faire. Donc j'ai une clé de distribution qui est l'État. C'est des données où j'ai pris les États américains. C'était le plus simple à faire que les départements français. Il y en a moins. Donc je vais charter les données par État. Donc ça veut dire qu'en gros tous les Californiens sont sur le même nœud et tous les New Yorkais sont sur un autre nœud peut-être, peut-être le même, en tout cas ils sont sur le même. Et puis j'ai une clé de tri qui est une clé composite avec le nom de famille et les premiers. Donc j'ai chargé mes données, donc comment on charge des données sur Redshift ? On fait ça. Désolé vous n'aurez pas ma clé secrète. Donc la commande copy c'est une commande de Postgres en fait qui existe. bon là qui a été adapté pour aller charger des données à partir de l'S3. Donc je charge à partir de mon bucket S3 qui est dans la région EU-West avec les credentials et je lui dis de compresser les deux. Si je regarde combien j'ai d'autres lignes, c'est un peu petit là aussi mais bon, faites pas confiance il y a un milliard de lignes. Si je regarde une ligne, je vois que j'ai effectivement le nom, le prénom, l'état, l'âge, le jour, l'heure, les minutes, le nom d'item et le montant de panier. Donc j'ai un milliard de lignes comme ça. Ah ! Voilà, catastrophe. Ok, alors après j'ai des requêtes idiotes comme ça par exemple. Je voudrais savoir qui des hommes ou des personnes dépense le plus voilà je vais me faire insouder c'est la data qui te disent c'est pas moi voilà donc en 5,8 secondes sans tricher j'ai fait ça sur un milliard de lignes et donc je vois que les femmes dépensent un peu plus alors généralement là il ya un mec qui me dit ouais ça il pas besoin d'un data warehouse pour le savoir et à ce moment là il se fait siffler. Je pourrais faire ça par exemple. Je pourrais dire voilà je vais trouver alors du coup si c'est les femmes qui dépensent le plus je veux savoir s'il y a une période de l'année à laquelle elles dépensent le plus par tranche de cinq jours. Toujours en SQL et là qu'est ce que je vais voir ? Donc je vois que ça se passe plutôt à la fin de l'année en fait. Entre 335ème et 350ème jour on dépense plus. C'est bizarre, il y a quoi cette période de l'année ? C'est Noël. Donc ça nous rassure parce que ça veut dire que les femmes dépensent mais en fait c'est pour nous. Donc voilà l'honneur est sauf. La data ne ment jamais. Après je pourrais dire tiens, quels sont les 10 dans lesquels les femmes dépensent le plus en décembre. Je me rends compte que c'est Washington DC, New York, la Floride, la Californie, etc. Et puis après, mon directeur marketing, on m'a dit, tu sais quoi, sors-moi les 10 000 femmes dans ces états qui ont dépensé au moins 500 dollars en décembre parce qu'on va leur envoyer Et là en fait on oblige mais je suis en train de faire ça sur un milliard de lignes. Et ça prend 10 secondes. Vous voyez quand je dis c'est simple, c'est qu'on a l'impression qu'on est sur un MySQL en fait, et qu'on query 10 000 lignes. Vous êtes sur un cluster, il y a 16 nœuds, il y a un milliard de lits. Et ça répond en 8-10 secondes et il n'y a pas de ruse. Vous pouvez le refaire. Si vous voulez mes 50 gigas de données et les charger, je vous les donne. C'est dans un bucket, vous refaites le test, vous aurez les mêmes perfs. Ok ? Donc voilà. Il n'y a pas d'arnaque. Donc voilà Redshift. Et puis évidemment on peut exporter. Ah là il y a des secrets. Merde. On coupe 3 en montage. Donc voilà Redshift. Bon, mais ça reste du SQL. Alors le problème c'est que ça c'est bien, mais votre directeur marketing ou votre product owner ou je sais pas quoi, lui il connaît pas SQL, il va vous poser des questions, il va vous créer des tickets, il va venir vous voir pour vous dire donne moi la liste des 10 000 de femmes qui ont dépensé le plus en décembre. Et tu vas dire, tu sais quoi ? Tu vas le faire tout seul. Il va dire mais non. Mais oui. Donc là, voilà QuickSight, on est très très fort en IHM chez AWS, mais au moins elle est simple. C'est simple, tu vas faire New Analysis, New Dataset, et puis après on va faire quoi ? Les données sont dans Redshift. Je vais te poser le micro. Donc il va me falloir le petit nom du hostname, le numéro de port, le nom de la base, le nom du user, mon password super secret, connect. Voilà, et puis on va aller dire, tu sais quoi, tu prends ça, tu vas dans la table sales, qui est ce qu'on veut, tu fais select, Et là il va commencer à charger les données. Pendant qu'il fait ça je vais vous expliquer un peu plus ce que ça. Voilà donc on va lui dire oui c'est pas stable, allez go. Ça je pense que c'est à la portée de à peu près tout le monde j'espère. Donc là il va commencer à charger les lignes. Il devrait voir le progress là. Qu'est-ce que c'est QuickSight ? QuickSight c'est un outil de business intelligence que vous allez voir qui se connecte à tout un tas de back-end au sein de AWS. Donc là j'utilise Redshift, je pourrais charger des fichiers à la main, tu pourrais charger les CSV, des choses comme ça, tu pourrais aller chercher des fichiers dans S3, tu pourrais faire plein de choses, tu pourrais aller chercher des fichiers dans HDFS, il y a plein de façons de le faire. Alors on peut en parler pendant deux heures mais une fois de plus je vais répéter, c'est simple, vous allez voir le truc, c'est à la portée absolument de tout le monde, il n'y a pas besoin du tout d'être technique pour utiliser cet outil là, c'est rapide, puisque c'est un C-app, ça s'appuie sur un moteur qui s'appelle SPICE qui est in memory. Je vais en parler juste après. Donc tout se fait en mémoire, pas d'accès à disk. Effectivement on peut avoir de gros data sets, ça va vite. On a des outils de visualisation qui sont simples. Ça marche directement sur mobile ou sur tablette. On peut partager ça sur d'autres terminaux. On peut partager Partagez les analyses, c'est-à-dire qu'une fois que vous avez fait une analyse sympa, vous pouvez la sauvegarder et l'envoyer, en fait, la partager avec vos collègues, sans partager le dataset, pour leur partager, en fait, le résultat de l'analyse qui est stocké en mémoire. Et eux-mêmes peuvent aller rezoomer et re-explorer votre analyse. Donc, une fois de plus, c'est un service qui est managé, donc il n'y a pas de serveur. Là, je n'ai rien créé, j'ai juste un compte et j'accède à ce compte. et ça coûte 9 dollars par user par mois. Là aussi, c'est peut-être pas vous qui payez les factures, comparé avec les systèmes X, Y et Z de la concurrence, vous pouvez rajouter quelques zéros après ça, par user, par jour. L'arme secrète, c'est ce moteur qui s'appelle SPICE, Super Fast Parallel In-Memory Calculation Engine. On a dit Superfaces, donc il a intérêt à l'être. Et donc l'idée ça va être ça, ça va être de charger tout le dataset en RAM, ce qu'il doit être en train de faire là. Mon milliard de lignes là, il va charger tout ça. Et puis on va pouvoir le disséquer, on va pouvoir l'explorer dans différentes dimensions, on va pouvoir le graffer, on va pouvoir faire des requêtes dessus, et le tout rapidement. Quand je dis rapidement, c'est-à-dire que c'est interactif et on n'attend jamais plus de quelques secondes quand on fait un gros traitement. Donc l'idée, ça va être toujours la même, c'est des data sources, comme je vous l'ai montré, qui vont fournir des données qui sont chargées dans Spice, et puis après on travaille interactif. Donc c'est un service qui a été annoncé à notre conférence à re-invent en octobre dernier. Il est encore en preview. Mais le simple fait que j'ai enfin réussi à avoir un compte, ça veut dire qu'ils sont en train de commencer à ouvrir les vannes. Donc qu'est-ce que c'est un service en prévu ? C'est-à-dire concrètement, vous allez sur la page QuickSight WS et vous pouvez demander à avoir accès. Et il est possible que vous l'obteniez. Ça a été très fermé pendant longtemps et là, ils sont en train de préparer pour être concrets. Donc vous pouvez commencer à jouer avec. Voilà, c'est assez sympa. On va passer à la deuxième démo. J'espère que vous chotez tous ma référence parce que sinon je vais être déçu. Ça mériterait presque 50$ de crédit AWS pour ceux qui trouvent. Voilà, vous voyez comment vous êtes. Il faut vous motiver. Bon, tu as gagné 50$. Viens voir à la fin, je te donne un code. Ce n'est pas une blague. Ceci dit, j'imagine que le nom a quelque chose à voir. C'est-à-dire que l'épice vous donne la clairvoyance. On va voir, on va essayer. On va brancher QuickSight sur nos données et on va voir si on devient clairvoyant ou pas. Je vais reposer ça. Je vais essayer de... Donc là il est en train de charger mais on va déjà pouvoir analyser. Dites moi quand vous voyez plus rien au front. Ça ne hurle pas encore ? D'accord, je vais essayer parce que sinon on ne voit pas les... Non mais ce qui compte c'est surtout le graph en fait. Je pense que la partie droite vous verrez sinon je grossirai. Donc là on a des dimensions. Donc là j'ai le nom, le sexe, l'état, etc. Et puis en dessous j'ai des mesures. Donc j'ai des valeurs numériques, j'ai l'âge, le basket, etc. pourrais essayer de faire pour essayer de faire le panier moyen le panier moyen par sexe voir si on retrouve la même valeur que tout à l'heure donc on va essayer de faire ça alors on a donc on va mettre gender on met le basket là alors là il fait la somme moi ce que je voudrais c'est Average Paf ! Vous voyez le truc ? Moi j'adore ça. Donc là qu'est-ce que je viens de faire ? Je viens de refaire l'équivalent de ma requête SQL de tout à l'heure. L'average basket par sexe. Donc là vous voyez peut-être pas, là c'est les hommes en bas, enfin si la barre est plus courte. Ça c'est les hommes, ça c'est les femmes. Donc je vois effectivement le panier moyen, j'ai la valeur qui apparaît là en pop-up. C'est 120 pour les hommes et 150 pour les femmes. En sachant que je n'ai pas encore tout le dataset, il ne m'a chargé que 21 millions de lignes. Ça doit être statistiquement représentatif. Voilà. J'imagine que ça suffit pour avoir une bonne idée. Je pourrais avoir le max. Donc le panier le plus élevé pour les hommes il est de 659 et pour les femmes il est 782 je peux avoir le plus petit enfin vous avez compris le truc ben c'est 0 parce qu'il doit y avoir des lits foireuses dans mon fichier ok alors on pourrait essayer donc voilà L'équivalent des requêtes que je faisais tout à l'heure, je l'ai fait là. Là, je n'ai pas besoin d'être informaticien, je n'ai pas besoin d'être quoi que ce soit. C'est un outil de BI normal. Le truc, vous allez me dire oui, ce n'est pas très beau. Je suis d'accord que pour l'instant, ce n'est pas très beau. C'est encore en évolution. Maintenant que j'ai accès, je vais pouvoir suivre un peu ce qui bouge sur ce produit. Mais moi ce qui me bluffe, c'est la rapidité du truc. C'est qu'en fait là on est en train de faire en une fraction de seconde, on fait des selects et on fait des group buy sur des millions de lignes et on a le résultat. Bon, il continue à charger son truc en tâche de fond. Alors essayons de faire ça. Alors on va essayer de faire justement... les états où les femmes dépensent le plus. Là on va mettre les états, là on va mettre les femmes, là on va mettre la drogue du basket on va laisser réfléchir deux secondes ah oui non là j'ai encore mes femmes ouais bah c'est pas les gens en fait voilà donc là j'ai les états le panier moyen des femmes le panier moyen des hommes je dois pouvoir trier voilà je vais faire sorte 10 cent Je vais zoom un peu et je retrouve bien mes trucs de tout à l'heure. Je retrouve bien le fait que c'est bien Washington DC, New York, Californie, Floride, où les femmes ne les pensent plus. C'est quand même plus sympa. Moi j'aime bien faire du SQL aussi, ça m'amuse. Entre ça et... C'est où est les 7 roquettes ? C'est celle là. Ça c'est hors de portée si vous n'êtes pas un peu informatissamment la main. Ça c'est jouable. Vous voyez quand on dit rapide, c'est rapide. On pourrait jouer avec pendant une heure. On peut faire des filtres. On pourrait appliquer des filtres. des requêtes SQL pour refiltrer les données en disant tu me donnes que les jones quel est le prénom du jones qui a dépensé le plus au mois de décembre dans l'Arkansas et puis il va nous le sortir aussi. Je ne suis pas sûr qu'on ait envie de savoir ça ce soir. Ok ? Et puis il y a d'autres choses à montrer. Voilà QuickSight donc encore en preview mais canon. Pour 9$ pour Moi je trouve que c'est quelque chose de prometteur. Il est probable que ce soit la première démo QXI en France aussi. C'est que des premières. Allez on enchaîne. Ça va vous êtes encore avec moi ? Bon on est à la moitié du hamburger. Je ne sais pas que vous avez encore faim. Machine learning. Machine Learning c'est un service managé, une fois de plus, ça c'est la bonne nouvelle, pas d'instance, pas de serveur, pas de cluster, rien à faire, qui va vous servir à une chose et une seule, c'est à construire des modèles de prédiction, sachant qu'aujourd'hui, c'est sur le slide d'après, aujourd'hui on ne supporte que la classification binaire, la classification multi-classes ou la régression linéaire. Donc soit on classe, soit on prédit des valeurs numériques. Il y a plein d'exemples de code que vous trouverez sur GitHub. Ça s'appelle Amazon Machine Learning, mais pour l'instant, c'est essentiellement la régression linéaire et la classification. Il n'y a pas la recommandation, il n'y a pas le il y a pas de truc là. Il est possible que ça vienne plus tard mais pour l'instant on les a pas. Et l'idée c'est vraiment, et bon je m'excuse s'il y a des data scientists pur et dur dans la salle parce que je vais les vexer là, tant pis maintenant on mangera un bout de pizza. C'est vraiment le machine learning pour les humains. Et je m'inclue là dedans. Ça y est ils sont vexés ? Ce que je veux dire par là c'est que dans d'autres vies j'ai bossé dans des boîtes qui faisaient beaucoup beaucoup de machine learning où il y a des équipes entières qui faisaient ça et c'était compliqué parfois de discuter avec eux, c'était compliqué de comprendre ce qu'ils faisaient, c'était compliqué de comprendre de quoi ils avaient besoin. Pour eux c'était compliqué de comprendre nos problématiques de parfaitement de scalabilité, etc. Pourquoi ? Parce que le machine learning c'est un domaine qui est super complexe, qui nécessite un background théorique fort, et quand on est dans les boîtes du web, a priori on l'a pas forcément ce background, on a des gens qui sont bons en développement, bons en infrastructures, etc. Mais voilà, vous commencez à leur parler de régression linéaire et de gradient et de je sais pas quoi, Le mec vous regarde, c'est extraterrestre pour vous. C'est extraterrestre. Donc c'est difficile pour des gens qui n'ont pas cette formation théorique de comprendre de quoi vous avez besoin et comment on travaille avec des data scientists, des gens qui font des machines de l'ordre. Donc l'objectif de ce service, c'est d'abolir tout ça et de faire en sorte qu'un développeur moyen, et même très moyen, soit capable de construire des modèles de prédiction et de les intégrer dans son application. Donc l'objectif c'est que la complexité soit complètement masquée et que vous allez voir en quelques clics on construise un modèle et on puisse l'interroger. Le revers de la médaille, c'est qu'il n'y a pas beaucoup de boutons, il n'y a pas beaucoup de leviers sur lesquels vous pouvez jouer. Et donc les data scientists pure et dure qui aiment écrire leurs algorithmes eux-mêmes parce qu'il y a eu un papier de recherche qui est sorti avant-hier avec le sens 59e tweak sur Random Forest ou je ne sais pas quoi, et ils veulent l'implémenter, ceux-là vont être hyper frustrés et ils vont dire, non mais ton truc c'est gentil mais c'est dur. C'est vraiment pour les noobs. Et oui, c'est pour les noobs. Amis noobs, en machine learning, ce service est pour vous et pour moi. Donc, ils s'intègrent avec les back-ends S3 et Redshift RDS. Il fournit quelques opérations de transformation de données, de visualisation, mais ça reste très léger. Le cœur du truc, ça va être de construire le modèle, de l'évaluer, de le scorer, et ensuite, évidemment, de le mettre à disposition pour faire des prédictions. On pourra faire soit en batch, soit en temps réel, et c'est ce que je vous montrerai avec une petite appli. Combien ça coûte ? Alors, 42 cents, pour la phase d'analyse d'évaluation de training. Ça ne paraît pas très cher, dans plus que la majorité des modèles ne vont pas nécessiter une heure de calcul, beaucoup moins. Et puis ensuite, les prédictions, on paye par prédiction. Donc si vous faites 1 million de prédictions temps réel, ça va vous coûter 1000 dollars ? C'est simple ? Parce que moi j'avais fait compte, non c'est 10 millions. Parce que moi j'en avais fait 10 millions, je m'étais enflammé. À l'époque où j'avais pas un compte ou quelqu'un payait des factures pour moi, j'avais fait 10 millions et ça m'avait coûté 1000 dollars. Donc c'est ça. Si vous faites 10 millions de prédictions, ça vous coûte 1000 dollars. Pour la petite histoire, j'ai créé un ticket au support AWS en disant « désolé j'ai fait une connerie » et ils m'ont annulé les 1000 dollars. Non, c'est vrai. Et ça arrive Il paraît qu'ils ont l'habitude avec les nouveaux services et puis les idiots comme moi. Ils ont dû faire tourner le mail, t'as vu, 1000 dollars, heureusement que je ne les ai pas payés. C'était mon compte perso. Alors, qui l'utilise ? Des gens qui ont à peu près rien à voir avec le monde du machine learning. Cette boîte là, Buildfax, c'est une boîte dont les clients sont des compagnies d'assurance et donc qui met à disposition de ces compagnies des informations sur l'état des bâtiments, l'état des toitures, etc. Donc ils vont collecter des millions et des millions, ou en l'occurrence même des milliards de data points sur l'état des bâtiments partout aux Etats-Unis, sur l'état des toitures, sur les travaux qui sont faits, etc. Donc ils vont récupérer tout ça. collecter les permis de construire, toutes ces données-là. Et puis à partir de ça, ils vont construire un modèle de machine learning qui va permettre via des API à leurs clients de savoir quel est le risque associé à tel ou tel bâtiment, à tel ou tel quartier, et donc de calculer des primes. Et moi je trouve cet exemple sympa parce que le business de la boîte, dire du mal d'éclure, le business de la boîte dit comme ça, il paraît pas très sexy, les mecs qui ingèrent des permis de construire pour savoir ce qui se passe, sur quel bloc, de quelle rue à Chicago, bon ok. Mais le fait de le faire intelligemment et de le faire à l'échelle, ça permet effectivement de créer de la valeur, ça permet à un assureur de savoir que tiens ce bâtiment là, cette année il y a eu des gros travaux et que peut-être c'est un risque ou au contraire peut-être c'est une amélioration. et du coup ça modifie la prime. Donc eux ils utilisent Amazon Machine Learning pour faire ça. Et on imagine que cette boîte là elle n'a pas une équipe de 60 data scientists. Et pourtant ils allaient faire quelque chose. Et puis on a un deuxième qui est plus récent, c'est Fraud.net qui est une boîte plus connue, qui est une plateforme collaborative de signalement et de détection de fraude e-commerce. Et donc l'idée c'est qu'ils vont collecter tout un tas de transactions e-commerce, et les gens peuvent aussi leur envoyer des transactions pour voir quelles transactions sont frauduleuses ou pas. Ça c'est un grand problème de l'e-commerce, moi qui aussi travaille dans l'e-commerce, de savoir que monsieur Jean Dupont qui habite à Toulouse et qui pour la première fois vient de passer une commande de 19 000 euros sur mon site. Alors est-ce que c'est un super client que je ne connaissais pas et qui vient dépenser 19 000 euros et je suis super content ou est-ce que c'est un escroc qui essaie de me voler 19 000 euros matériels ? Donc quand les gens ont commandé 250 fois chez vous, a priori vous savez si c'est des escrocs ou pas, j'espère qu'ils ne le sont pas sinon vous n'avez pas été très vigilants. Mais le problème de la première commande, c'est un problème compliqué dans l'e-commerce parce qu'on a peu d'infos, on n'a pas d'histoire. Donc Fraud.net fait ça et les critères qui permettent de dire qu'une transaction est frauduleuse, il y en a plein, on peut en imaginer, se faire livrer à une boîte postale. Typiquement c'est ça, la première commande avec un montant très élevé. Généralement ça déclenche, essayez ça sur un site e-commerce plus ou moins équipé en intelligence, vous allez voir ce qu'il se passe. Vous allez avoir un coup de fil où on va vous demander une copie de votre pièce d'identité. Ce qui va arriver plein de fois. C'est super de faire de l'e-commerce, mais quand je dois scanner mon passeport et l'envoyer par courrier ou par mail, c'est une absurde. L'idée, c'est de faire ça intelligemment. Donc, eux, ce qui leur plaît, c'est qu'en fait, il y a plein de critères différents pour détecter si une transaction est frauduleuse. Du coup, ils vont créer plein de modèles différents. Ils n'essaient pas de faire le modèle ultime avec les paramètres parce que ça c'est compliqué à faire. Il peut faire plein de modèles différents sur plein de critères différents et puis appliquer les différents modèles et puis voir s'il y en a un qui sonne la larme ou pas. Et ça effectivement avec Amazon Level c'est facile de créer plein de modèles, c'est facile de les rafraîchir. On peut créer autant de modèles qu'on veut. Donc, fraude .NET c'est intéressant. Alors démon numéro 3, donc on va charger des données à partir de Redshift, on va construire un petit modèle, alors comme ça tourne 10 minutes on va pas regarder le truc qui tourne pendant 10 minutes, je vais le lancer et puis on va en regarder un que j'ai déjà construit et puis surtout après on va faire des projections. Alors voilà la console machine learning. On peut créer plein de choses différentes. On peut créer des datasources. Le nom est explicite. C'est où est-ce que je vais aller chercher mes données, soit dans Redshift, soit dans S3. Je peux créer un modèle. Je peux créer une nouvelle évaluation pour un modèle pour voir si le modèle est fidèle ou pas. Là, on va faire create data source ML model. On va tout faire en mineta. on va lui dire d'aller dans redshift voilà le nom c'est toujours même le rôle de pouvoir prendre celui-là. Ce qui est sympa quand on charge à partir de Redshift, c'est qu'on va pouvoir faire un select. On va aller dans l'autre fenêtre. On va regarder la table. C'est toujours les mêmes données, c'est juste là j'ai mis que 10 000 lignes parce que j'ai pas envie de construire un modèle sur un milliard de lignes. Donc on va prendre quoi ? On va prendre gender. On essaie de faire un modèle qui va prédire le panier moyen. Enfin pas le panier moyen, qui va essayer de prédire le panier de l'internaute. Donc tout à l'heure on a vu que le sexe était important. Je pense qu'on va prendre l'âge, on va prendre l'état, parce qu'on a vu qu'il y avait des différences entre les états. On va prendre le jour, parce qu'on a vu qu'à Noël il se passait des trucs, donc ça peut être un paramètre intéressant. Et puis on va prendre basket. Donc là on l'a vu. C'est tout, j'oublie rien. et puis on va créer une datasource qu'est ce que j'ai oublié ? Ah oui il voit un bucket intermédiaire sur S3 très bien on va lui donner ça et avec ça il va se débrouiller. On va faire verify donc là il va vérifier qu'il peut se connecter à Redshift il va vérifier qu'il comprend un peu ce qu'il y a dans la table C'est bon. Donc là, Amazon ML sait se connecter à mon Edge. Il dit « Ok, je comprends ce qu'il y a dedans ». On continue. Donc là maintenant, il me dit « Voilà, j'ai trouvé donc cinq colonnes. Dis-moi un peu qui est quoi là-dedans. » Alors « Gender », est-ce que c'est « Texte » ? Moi j'ai envie de dire que c'est plutôt une catégorie. L'état. Alors là on ne va pas débattre, mais est-ce que c'est du texte ou est-ce que c'est une catégorie ? C'est plutôt une catégorie, enfin en l'occurrence on ne va pas faire de classification dessus. Donc on va le laisser en texte. Le jour c'est numérique, le basket c'est numérique, l'âge on pourrait aussi débattre est-ce que c'est une catégorie ou est-ce que c'est une valeur, on va lui dire que c'est une valeur. très bien continue ah et là il me dit bah oui mais coco qu'est ce qu'il faut prédire et ben tu vas prédire basket continue parce qu'il y a des identifiants donc il n'y a pas d'identifiant donc là il me dit bon voilà j'ai tout bien réfléchi donc c'est ça que tu veux faire ok Donc tu m'as dit de charger les données à partir de là, tu m'as dit que les attributs sont comme ça, tu m'as dit qu'il faut prédire le basket donc je vais faire une régression linéaire. C'est bien ça, on continue. Voilà et là il va charger les lignes, ça ne devrait pas être très très long si on démarre. Qu'est ce qu'il est en train de faire ? Vous voyez, on la voit, il est en train de faire le fameux unload. Je l'ai très furtivement montré tout à l'heure. Donc le unload c'est sort de sors moi dans un csv ces données là. Donc il est en train d'exécuter la requête. il va la mettre dans un CSV qui va dans le bucket où je lui dis de la coller. Donc là on a construit la data source en haut. Maintenant on va s'occuper du modèle. Le modèle c'est un modèle d'organisation linéaire puisqu'on lui demande de prévenir. On va lui donner un nom qui est très bien. On pourrait faire les custom settings comme ça vous voyez un peu ce qui se passe dedans. Il est encore en train de faire l'extract. Non mais on s'en fiche. C'est pour nous montrer ce qu'il y a dans le tableau. On se doute que c'est ce qu'on veut. Donc là, voilà, ça c'est à peu près les seuls paramètres que vous pourrez appliquer sur le modèle. Alors là, on va voir qui sont les data scientists. Donc la taille du modèle, le nombre de passes, est-ce qu'on va mélanger les données ou pas ? Alors ça, ça peut être utile quand vous avez des données qui sont triées. Par exemple, vous avez avez des données qui sont triées par date d'accord imaginez vous avez des transactions qui sont toutes triées par date croissante alors vous allez dire pourquoi c'est un problème c'est un problème parce que quand il va splitter la data source en deux il va prendre une partie pour faire le training et une partie pour faire l'évaluation donc là en l'occurrence si j'avais trié mes transactions par date tout noël serait à la fin ce qui veut dire que dans mon modèle je n'aurai pas la partie intéressante en fait. Donc si vous avez des données qui sont triées et que vous voulez les mélanger, vous pouvez les mélanger. Là on va lui en montrer qu'on est tranquille. Vous pouvez choisir le niveau de régularisation que vous appliquez. Donc comme vous avez tous fait le Coursera de Andro, vous savez ce que c'est que la régularisation, je n'explique pas. Je serai bien en tête d'une expliquant en 30 secondes. Donc on va faire continue. Est-ce qu'on va évaluer le modèle donc bah oui on voudrait savoir quelle est la qualité de ce modèle un petit nom le split voilà donc justement là est ce qu'on fait un split random ça c'est un split séquentiel donc on va laisser séquentiel on va faire review voilà qui va dire j'ai tout bien compris c'est tout ça que tu m'as demandé finish Voilà, et là, théoriquement c'est parti, bing ! Donc là, qu'est-ce qu'il fait ? Il prend le CSV qui est dans S3, il le mélange, on va lui demander de le mélanger, il le split, il va prendre une partie pour faire le training, puis une partie pour faire l'évaluation. Donc ça, ça va tourner une dizaine de minutes sur cette taille de données-là, on ne va pas perdre 10 minutes, je vais vous montrer ce que ça donne à la fin. Donc ça je l'ai déjà fait. Voilà c'est modèle 2. Alors vous voyez ça y est il est parti. Donc il a splitté. Donc ça c'est la data source initiale qu'il a splitté en deux pour l'évaluation pour le modèle. Bon et puis quand il aura fini le split il fera le modèle et puis après une fois qu'il aura fait le modèle il fera l'évaluation. Donc on va avancer là dessus. Voilà donc ça c'est le résultat définitif. Je vois toujours mes deux data sources, je vois mon modèle qui est là et je vois l'évaluation. Donc si je clique sur... Est-ce que ça vaut la peine de regarder data source ? Ouais, rapide peut-être. Donc là je vais voir quelques infos sur mes données, je vois la distribution des données, exemple donc là je vois la distribution des paniers moyens. Ça permet d'avoir un avis rapide sur ok c'est quoi ce dataset. Je vois mes attributs, il n'y a pas de binaries mais il y a peut-être des catégories. Voilà donc je vois qu'il y a deux valeurs pour gender, on peut en penser ce qu'on veut mais il me semble que moi il n'y en a que deux. Il y a haut des femmes, pas de polémiques. les états il y a 56 valeurs, alors vous allez me dire il y a 51 états aux états unis mais il y a quelques îles rattachées aussi aux états unis, le nombre de jours dans l'année il y en a 365 là ça va on est en terre inconnue etc etc et puis on voit la corrélation ça c'est un paramètre intéressant donc on voit que il y a une corrélation très très faible entre le sexe et le basket, corrélation un petit peu plus sur l'état une corrélation un peu plus forte encore sur le jour donc voilà le fait d'ingérer les données ça vous donne déjà ces paramètres là ça vous permet de dire ok finalement cette colonne là j'avais pas besoin de la mettre dans le modèle au contraire elle est vraiment cruciale il faut que je vais donc on va retourner On va regarder l'évaluation. Et on va voir une chose, c'est que mon modèle est pourri. Pourquoi ? Parce que mes données sont pourries. Donc c'est des données que j'ai générées n'importe comment. Donc j'ai la même Il me l'a montré sur l'écran d'avant, j'ai envie de vous le dire. Donc la mesure standard sur les modèles de réglation linéaire, c'est la root mean square error, c'est à dire en gros l'erreur moyenne qu'il y a sur la valeur prédite. Donc là quand je dis que mon modèle est pourri, il est pourri parce que j'ai des baskets qui sont en gros de 150, 140 dollars et j'ai une erreur moyenne de 50. Donc ma courbe, ma distribution, elle devrait être beaucoup beaucoup plus serrée. il est beaucoup trop étendu. Donc ça c'est la faute des données, ça n'a rien à voir avec le machine learning, c'est juste que mes données ne sont pas terribles. Bon, mais voilà, c'est pas grave. Pour démontrer le machine learning, c'est pas très important. Donc ok, j'ai pas un très bon modèle. Si j'avais fait un classifieur, j'aurais le F1 score sur faux positif, faux négatif, etc. d'ailleurs on pourrait le régler. Je n'ai pas le temps de vous le montrer ce soir mais quand on fait un classifieur on peut tweaker le paramètre qui ajuste faux positif versus faux négatif parce que dans certains cas c'est pas du tout la même chose. Si vous essayez de détecter des gens qui ont le cancer, est-ce qu'il vaut bien un faux positif ou un faux négatif ? Bon, je préfère qu'on me dise que j'en ai un et que j'en ai pas. Je préfère qu'on me dise que tout va bien et que... Bon, bref. Vous m'avez compris. Excusez-moi. On a ce modèle et une fois qu'on a le modèle, on a envie de faire des redactants et predictions. On pourrait les faire à la main dans la console. Je pourrais essayer ça. 45 ans, femme, Californie, 234e jour de l'année. Donc C'est bizarre. Donc là, ce que j'ai fait, c'est que j'ai créé... Alors, en un clic, là, c'est fait, mais il y a un clic à faire ici pour Enable Real-Time Prediction. Donc, il va créer un endpoint que vous pouvez invoquer, sur lequel vous allez pouvoir faire un poste HTTP pour obtenir un résultat. Donc, c'est ce que je vais faire. J'ai codé un bout de Java. Je vais vous infliger. Donc... ça c'est pas très important c'est juste pour récupérer les credentials ce qui est plus important c'est peut-être un peu gros alors je vais peut-être essayer de plus tente Ouais, un peu mieux. Donc, je vais récupérer la liste des modèles qui existe. Je vais passer en ligne de commande l'identifiant du modèle que je veux invoquer. Donc, je commence par récupérer la liste des modèles. Je cherche le modèle dont j'ai passé le nom, l'identifiant en ligne de commande. OK. Une fois que je l'ai trouvé, je vais afficher tout un tas d'informations dessus. Je vais récupérer les informations sur son endpoint. Je vais afficher aussi. Voilà. Et puis ensuite, j'ai créé une requête de prédiction. Je vais l'associer au modèle. Je vais sélectionner le endpoint de ce modèle. Ensuite, j'ai un petit builder. C'est Java dans toute sa gloire. Voilà. petit builder pour construire la requête donc là où je vais construire à partir des paramètres qui sont passés en ligne de commande et puis je vais l'envoyer la requête de prédiction. Je chronomètre combien de temps elle prend. C'est pas très compliqué et puis j'affiche le résultat. Alors on va faire ça. Donc là je me connecte sur une instance EC2 sur laquelle j'ai copié mon sur lequel j'ai copié mon genre et puis je vais l'appeler, ça évite de taper. Donc je passe l'identifiant du modèle, l'âge, le sexe, l'état, le jour de l'année. Je vois quoi ? Je vois ce que je vous ai dit tout à l'heure. je vois le nom du modèle je vois bien que c'est un modèle de régression linéaire je vois que c'est un gradient descent je vois d'où viennent les données je vois le endpoint et surtout je vois la valeur prédite selon mon modèle cette rame va dépenser 194 dollars et je vois que ça a pris 96 millisecondes sachant que le SLA est à 100 donc on est dans le SLA on va en essayer bien d'autres on va voir si à noël elle dépense plus Ben oui, il dépense plus. Ok ? Bon, on va continuer à jouer deux heures comme ça. Vous avez compris ce truc. Et donc, juste pour expliquer ça, finalement, la partie la plus compliquée de toute cette histoire, c'est ça. C'est-à-dire qu'aujourd'hui, il y a plein d'outils open source pour construire des modèles, mais mettre ce modèle à disposition d'une appli de temps réel, là on pourrait l'intégrer dans une appli web, ça c'est beaucoup plus compliqué. compliqué. Il n'y a pas vraiment de solution simple pour le faire aujourd'hui. On est obligé de faire toute la plomberie. Vraiment la valeur ajoutée d'Amazon Machine Learning c'est ça. C'est d'arriver sur « ok, create endpoint et ça y est maintenant je peux brancher de la prédiction et de la réglation dans mon appli. » C'est ça la partie difficile. Ce n'est pas de construire le modèle maintenant, vous faites du R ou vous faites du SILIP ou tout ce que vous voulez et vous construisez tous les modèles que vous voulez. Le truc après, c'est comment je le plug sur une appli web. Et ça c'est plus compliqué. Personne n'aime développer des applis. Ok ? Ça vous va ? Et bien on va se finir avec... C'est bon, il me reste encore... J'ai fini dans 5 minutes, je sais que vous avez faim. Mais je vais contre toute attente réussir à tenir l'entend. Donc, ce que j'ai dit tout à l'heure, c'est Amazon Machine Learning, c'est... de la prédiction, de la régression linéaire, de la classification. Donc tout le monde me disait « ouais non d'accord mais quand est-ce qu'on a la reco, quand est-ce qu'on a la reco, et pourquoi on n'a pas la reco Amazon, et quand est-ce qu'on a la reco Amazon, ça serait bien d'avoir la reco Amazon ». Et je disais « bah oui mais vous comprenez d'abord c'est Amazon donc c'est AWS, les gens ne comprennent pas la différence mais il y en a une ». Et puis je m'étais toujours dit « la reco Amazon c'est un truc un peu stratégique, je ne sais pas si un jour ils vont l'ouvrir ». Ce matin, en me levant à 6 heures, et en regardant mes feeds RSS, c'est ce que je fais à 6 heures, désolé. J'ai vu ça, et je me suis dit, non mais c'est pas croyable, ils l'ont fait. Et donc, ils ont au plan sourcé sur GitHub, donc Destiny, qui veut dire Deep Scalables par Stensor Network Engine, ils se sont vraiment fait plaisir sur le monde. Et en fait, mon avis, c'est qu'ils avaient choisi ce nom-là, et puis après ils se sont dit comment on fait un truc qui colle avec le drone. C'est pas possible d'avoir inventé ce nom-là, je ne peux pas y croire. Et donc en fait c'est une solution basée sur des réseaux de neurones. Pareil, vous avez vu le cours d'Andrew, si vous ne l'avez pas fait faites-le, je ne peux que souligner ce qui a été dit en introduction sur les MOOC Coursera Machine Learning, ils sont super. Vraiment celui d'Andrew c'est le c'est vraiment le meilleur point d'entrée. Il faut que je fasse celui de Deep Learning, je ne sais pas si j'ai le niveau. Et donc c'est Horizon Neurone et il est dans la doc, on dit explicitement qu'Amazon l'utilise pour la recommandation de produit. Donc on ne va pas faire un cours sur Horizon Neurone, je ne suis pas la bonne personne pour le faire. Les points clés c'est ça, cet outil a été construit pour gérer des grands réseaux. Parce que l'idée quand on fait de la reco produit c'est de pouvoir mettre des millions et des millions de produits. Je ne sais pas combien il y a de produits sur Amazon mais un nombre phénoménal. Ou au moins de le faire par catégorie de produits. Imaginez les CD par exemple et les livres. On n'est pas sûr, on ne va peut-être pas faire de la reco entre les chaussures et les livres, quoique il y a peut-être des corrélations, je n'en sais rien. Mais ne serait-ce que les livres, ou les disques, ou les montres, ou je ne sais pas quoi il y a des milliers voire des millions d'items donc il faut être capable de faire des réseaux de grande taille et surtout il y a raison qu'ils sont creux c'est à dire qu'il y a plein de... tout ça c'est à la fin on est d'accord que c'est des matrices et dans une matrice comme ça il va y avoir plein de zéros parce que quand vous avez un million de cd il peut mettre la matrice un million par un million il y a beaucoup de zéros. Statistiquement, il y a très peu de gens qui ont acheté, par rapport au nombre total de transactions, très peu de gens qui ont acheté la même paire ou le même triplet de CD. Et puis il y a beaucoup de corrélations qui n'ont aucun sens. Si vous êtes fan d'Eminem, quoi que je vais dire une connerie, je ne vais pas dire. Si vous êtes fan d'Eminem, il y a peut-être peu de chance que vous soyez fan de l'Opera Degner, par exemple. C'est pas un gisom de valeur, même si je suis pas fan d'Eminem. Vous voyez, il y a plein de combinaisons qui n'existent pas, et puis la taille de la matrice par rapport au nombre d'items, au nombre de samples que vous avez, il y a un gros décalage aussi. Tout ça pour dire que cette matrice là, elle va être extrêmement creuse, et donc du coup il y a la place pour l'optimisation plutôt que de calculer des opérations des zéros qui ont aucun sens. Donc tout ça, ça tourne sur GPU, ce qui tombe bien parce que sur AWS on a des instances GPU, c'est ce que je vais vous montrer. Donc ils ont été un petit peu jésuites parce que leur premier bullet point c'est ça, c'est Multi GPU Scale et dans ce qui a été annoncé, dans ce qui a été réalisé cette nuit, bon c'est single GPU pour l'instant, donc c'est coming soon. Pour l'instant on ne peut pas tourner sur plusieurs instants GPU. Vous pouvez le faire en local, vous pouvez le faire sur du Docker ou sur AWS, c'est ce qu'il y a à faire. Donc vraiment, pour les gens qui ne connaissent pas ce genre de truc, ils disent « ouais, ça a l'air obscur », moi je pense que c'est majeur ce truc-là, vraiment majeur et un peu inattendu à mes yeux. Mais c'est vraiment un événement majeur. Et le fait qu'Amazon dise c'est le truc dont on se sert en interne pour la reco, ça c'est encore plus majeur parce que Amazon, vous l'aurez remarqué, c'est pas une boîte qui communique énormément sur ce qu'elle fait en interne. Donc voilà, je trouve que c'est un événement important et je suis très curieux de voir ce que va donner ce projet. La logique voudrait que ça, ça se retrouve intégré dans Machine Learning pour que en trois clics vous puissiez faire des modèles de reco pour les nouveaux. comme moi. Voilà, je pense que ça va venir. Je pense que ça va venir, ça serait logique. Maintenant, ne prenez pas ça, ne tweetez pas, Julien a dit que, d'abord j'étais engueulé, et en plus j'en sais rien. C'est juste mon opinion. Allez, dernière démo. Les dieux de la démo étaient avec moi jusque là, j'espère que ça va durer. Donc, le schéma est tout simple, donc créer une instance GPU sur un sur AWS, ça je l'ai déjà fait parce que c'est pareil, c'est clic clic clic. On va compiler la librairie, on va charger des données et puis on va entraîner un modèle. Allez c'est parti. donc là je suis sur une instance GPU donc c'est les instances G2 sur AWS. Qu'est ce que j'ai fait ? j'ai fait assez peu de choses pour l'instant voilà j'ai fait un clone du repo git voilà c'est tout j'ai dû positionner un pass bon c'est dans les C'est sur le GitHub, je vous ai pas mis les étapes. Je crois que j'ai fait Make. Voilà, c'est déjà compilé. On s'en fout de la recompiler. Ça compile pendant 5 minutes. C'est pas le truc le plus intéressant de la Terre. Ensuite, on va utiliser un dataset qui est... C'est un dataset qui est movilens, je pense que certains d'entre vous connaissent. C'est un ensemble, c'est le grand classique, c'est des recommandations, c'est des utilisateurs qui disent voilà moi j'aime tous ces films là. Et puis donc là on va prendre le gros modèle où il y a 20 millions de notes, par à peu près 138 000 users. Donc le but du jeu, c'est de construire un modèle qui va dire « Ok, tu as dit que tu aimais tout ça, donc nous on pense que tu vas, en fonction de ce que les autres ont dit, tu devrais aussi aimer ça. » C'est la boîte. Les gens qui ont acheté ce produit ont aussi acheté… Quoi que non, c'est les gens qui ont regardé ce produit ont aussi regardé. Parce que s'ils l'ont acheté, c'est un peu différent. Donc c'est typique de ces problèmes-là. Donc en avant, j'ai les commandes là. Donc le premier truc qu'on fait, donc ce fichier, je vais quand même vous le montrer 5 secondes, il est imbuvable, juste pour voir ce qu'il y a là-dedans, c'est particulièrement imbuvable. Alors les lignes sont énormes, parce que celui-là manifestement il a aimé plein de trucs. Donc là on a une ligne, et là en dessous on a une autre ligne. Donc là qu'est-ce qu'on voit ? J'interprète parce que je n'ai pas tous les détails sur le dataset, mais ça me paraît relativement clair, si les gens ne sont pas d'accord dans la salle, dites-moi non. Donc ça je pense que c'est un user ID, et puis ça, ça doit être probablement un timestamp, et ça, ça doit être l'identification du fil. Donc j'imagine que le user 3 est a dit moi j'aime le film 62, le film 70, le film 110 etc. Donc il a aimé tous ces films là. Sur chaque ligne en fait on a les ratings de chaque utilisateur. Si on compte les lignes, on voit qu'il y a 138 000 lignes. Donc il y a 138 000 utilisateurs qui ont dit voilà moi j'aime tout ça. Donc ce fichier là il va falloir le mettre dans un format qui est ingérable par notre modèle. Il y a deux commandes, enfin une commande qui est Generic NetCDF. NetCDF c'est le format de fichier qui va être utilisé pour construire le modèle. Le format est décrit dans la doc, je vous passe les détails. Donc là on va générer Alors, il doit nous manquer en place. Ah oui, il nous manque en place. Yes. Voilà, il fallait que ça merde. Ça y est. La commande de la... Donc là, ce qu'on fait, on va construire, je m'excuse si vous ne connaissez pas du tout les raisons de neurones, ça va vous paraître hyper ésotérique. Un réseau de neurones, il y a une couche d'entrée, donc on met les données d'entrée, il y a une couche de sortie où il y a les résultats. Et puis là, on va avoir une couche intermédiaire qui va servir à faire le training. Et donc le but du jeu, c'est de lui dire voilà l'entrée, voilà la sortie, et puis fais l'apprentissage sur les neurones, mets les bons poids sur les bons neurones pour que, à partir de cette entrée tu puisse me produire cette sortie voilà donc c'est vrai c'est quand même assez rapide on va faire la même pour la sortie donc là on fait que de la génération on fait pas du training pour l'instant là c'est vraiment juste du formatage c'est assez rapide et donc ensuite on va faire cette commande d'entraînement on y voit là donc il y aura 200 on va faire 250 comme s'il passe. On va laisser un exercice et ça. Ça devrait pas être très mou. Allez, n'empêche-toi. Voilà donc là on a la couche d'entrée, on a la couche de sortie, ils sont au bon format et là on est sur des fichiers binaires donc je ne peux pas vous les montrer. C'est ces fichiers .nc là. Et donc maintenant, On va faire le training. Donc il y a un fichier de configuration. Je vais lancer le training et puis je vous mets le fichier. Donc c'est un fichier de JSON. Chez AWS, on a bien le JSON. Donc il y a quelques paramètres. là je m'attarde pas ce qui est important c'est surtout ça c'est bien il y a donc trois couches on a une couche d'entrée avec le dataset jl input on a une couche de sortie avec le dataset jl output et donc le but du jeu maintenant donc c'est un réseau qui est fully connected c'est le seul type de réseau qui est supporté pour l'instant donc tous les enfin vous imaginez un réseau en haut de tête donc toutes les toutes les tous les neurones de la couche intermédiaire reçoivent des entrées de toutes les entrées et sont connectés sur toutes les sorties ça fait pas mal de connexions et donc au milieu on a une couche de 128 neurones qui avec une fonction d'activation sigmoïdes et donc c'est ça qu'on va entraîner on va essayer de trouver les bons poids sur les connexions ça tourne Ça ne devrait pas être très très long, je l'ai refait tout à l'heure, ça devrait durer 2-3 minutes. Donc là, il est en train d'essayer de trouver tous les poids sur toutes les connexions. Et c'est là qu'on comprend qu'il faut un GPU quand même. Si on en avait plusieurs, on irait encore plus vite. Et donc une fois qu'il aura fini ça, on pourra faire la prédiction. pour sortir la liste de films pour tous nos utilisateurs. Voilà, c'est terminé. Ça va durer quoi ? Une minute trente ? Je ne sais pas comment le mettre. Ce que je veux dire, c'est que ça va vite. Quand on voit la taille du problème, si vous avez joué avec des raisons de neurones en octaves ou en R, ou un truc comme ça, même quand on met 8 neurones milieu c'est bon. Là on a 128 euros mais on a pas mal d'entrées et on a pas mal de sorties. Donc en avant pour la prédiction, donc là ce qu'on va lui dire c'est écoute pour tous les users tu nous sors une liste de films. Donc il va faire tourner ça et on va récupérer en sortie normalement un fichier de 138 000 et quelques lignes avec je crois que c'est 10 films par user. Voilà c'est pareil ça ça dure peut-être une minute. Donc on va avoir la liste des 10 films par user avec le score, puisqu'on aura un score pour chaque recours entre 0 et 1 en fonction des ratings qui ont été faits par l'ensemble des utilisateurs. Allez ! Donc là il est en train de faire la traduction. Donc il va s'arrêter. Donc là on a un fichier maintenant, on va compter les lignes. 138 000 lignes, donc pour chaque utilisateur, user one, on a donc le user one il y a 93 % de chance qu'il aime le film 1197, 89 % de chance qu'il aime celui là, 84 % de chance qu'il aime celui là, etc. Donc concrètement on a fait quoi ? On a pris 22 millions de recours fait par 138 000 personnes, on a construit un modèle en quoi ? Allez, en comptant tout, moins de cinq minutes, moins de cinq minutes avec le formatage des fichiers et 6 minutes on a fait la prédiction sur un dataset déjà conséquent avec une couche de neurones, enfin avec 128 neurones au milieu donc un réseau déjà significatif. Je n'ose même pas imaginer ce qu'il faudrait déployer en infra traditionnelle et on sort de traditionnel pour faire ça. Je ne vois pas. S'il fallait le faire à la mano c'est compliqué. Voilà donc voilà Destiny sorti cette nuit. Vous pouvez tout refaire c'est vrai c'est l'exemple qu'il y a dans la doc. Je m'excuse de faire l'exemple qu'il y a dans la doc mais matériellement c'était absolument impossible de faire autre chose. La suite sympa de la démo ça serait de prendre tout ça, de mettre dans DynamoDB, de brancher des API, d'afficher ça dans une appli web etc. Bon, même pour moi c'était compliqué à faire en ligne de journée. Ok ? Bon voilà des styles. En tout cas ça me parait un truc bien prometteur. Je suis impatient de le voir intégré. Voilà, j'ai terminé. Donc on a des user group. Alors il y a des gens qui la salle qui m'ont promis d'en créer un à Toulouse. Je ne vais pas les dénoncer mais il y a lui et lui au fond. Je vais les saouler à la bière jusqu'à ce qu'ils disent oui. Donc on va vraiment se faire à Toulouse parce que bon, il y a du monde, c'est super, tout se passe à merveille. Et puis il n'y a pas de raison qu'il y en ait dans d'autres villes et pas chez vous. Il en manque un en bas à gauche et puis il en manque un en bas à droite. Il travaille aussi sur Nice et tout ça, et Marseille et tout. Voilà on a un groupe sur Facebook si vous voulez nous rejoindre et puis on a aussi un Twitter si vous voulez nous suivre. Alors le dernier truc que je voulais vous dire c'est qu'on a un événement le 31 mai à Paris qui est le Summit. Donc c'est chaque fois ça me fait ça. C'est notre conférence technique annuelle. Alors c'est gratuit donc pour vous c'est juste un billet d'avion. Mais si j'ai réussi à prendre EasyJet, vous devriez réussir à prendre aussi. C'est tellement agréable de prendre des idées. Ils sont tellement à l'heure, tellement charmants. Blague à part, si vous avez envie de découvrir AWS, soit d'approfondir vos compétences AWS, venez. Franchement, venez. Si vous arrivez à vous libérer du boulot une journée, vendez-le votre patron. Mais ça vaut vraiment la peine. Il y aura des confs techniques, il y aura clients, on va avoir des beaux clients sur scène, on va avoir AXA, on va avoir des startups, il y en a d'autres, je n'ai pas encore le nom de les citer, mais il va y avoir de belles références clients qui seront présentes. Il y a le CTO d'Amazon qui sera là, en keynote, Werner Fogles, généralement c'est assez marrant et assez sympa d'écouter. Et puis voilà, il y aura une bonne partie d'équipe française qui sera là pour répondre à vos questions. Donc si vous pouvez venir le 30 c'est avec plaisir. Voilà j'ai terminé, j'ai débordé un petit peu mais je voulais vraiment vous montrer tout ça ce soir, ça valait la peine de prendre un petit peu plus de temps. Merci beaucoup, merci encore de l'invitation et puis il y a mes coordonnées je vous les remontre, voilà, il y a mon adresse de mail et mon twitter, n'hésitez pas si vous avez des questions, je suis là pour ça. Voilà, merci à vous et puis je crois que c'est l'heure des pizzas. S'il y a des questions, on peut prendre les questions. Sinon, on peut discuter tranquillement autour de la pizza aussi. Donc je tienne encore 10 minutes pour l'épisode ? Alors on va faire un classifiaire ou un multi-class ? Non, non. Est-ce qu'il y a des questions ? Allez-y. Il me reste un peu d'énergie. Il y en a eu tout au fond. Il a levé la main d'abord. Oui, alors la question, c'est est-ce qu'on peut estimer le temps de construction du modèle parce qu'on paye à l'heure ? Alors non, il n'y a pas d'indication. Moi, mon expérience, c'est... Là, le modèle que j'ai fait sur 10 000 lignes, ça prend moins de 10 minutes. Donc je ne sais pas si on peut dire une minute pour 1000 lignes, je n'en sais rien. Il faut tester. Mais sincèrement, ça ne peut pas être très très long. Je dirais que ça va être du même ordre de grandeur que ce que vous arrivez à construire avec Saiki. ou avec des trucs comme ça, c'est les mêmes algos. Bon voilà, ça tourne peut-être sur des machines un peu plus grosses chez nous, mais ça ne doit pas tourner très très longtemps. J'avais fait le bourrin avec des modèles de 1 million de lignes et des trucs comme ça, et ça ne durait pas du tout une heure. C'était rapide. Bon voilà, après, je pense que ce qui va coûter cher, c'est plutôt les prédictions. À partir du moment où vous mettez en prod, si vous commencez à faire 100 000, 1 million d'appels par jour, ça va vous coûter plus cher. Mais le coût du modèle lui-même doit être assez négligeable. Et puis surtout, j'ai envie de dire, si c'est un bon modèle qui prédit correctement, contrairement au mien, parce que mes données sont pourries, vous allez économiser de l'argent. Donc vous serez content de payer 42 cents pour venir de calcul si vous générez des ventes. C'est un produit où il doit y avoir un ROI assez clair, sinon vous ne l'utilisez pas. Il y avait une autre question devant Alors, donc là, sur Amazon Machine Learning, ce qui se passe derrière, on peut avoir plein d'idées sur comment c'est fait. Moi personnellement, je n'ai pas les détails sur l'implémentation. Vous pouvez imaginer ce que vous voulez. Vous pouvez imaginer que ça tourne derrière sur un cluster à double, tout ce que vous voulez. J'ai envie de dire, ce n'est pas le problème. Ce n'est pas le problème. Le service est fait pour être le plus simple possible. Et justement, on ne veut pas avoir à se poser ce genre de questions. Si vous avez besoin de vous poser ce genre de questions, Il y a une autre façon de faire du machine learning, c'est de faire des clusters EMR, donc Elastic Map Reduce, où vous pourrez faire du Hadoop, vous pourrez faire du Spark, vous pourrez faire... Là vous aurez le contrôle, vous pourrez vous loguer sur les instances, et vous pourrez déployer vos jars et faire tout ce que vous voulez là-dessus. Donc ça c'est encore une autre démo, mais c'est vrai que j'en ai pas du tout parlé. Si vous avez besoin de contrôler finement ce qui se passe, si vous avez envie et besoin de développer vos job map reduce en Java, si vous avez besoin de faire du Spark finement et de tout contrôler, etc. Alors à ce moment-là, effectivement, faites du EMR. Et là, tu pourras choisir le nombre de nœuds, la taille des nœuds, et là, avoir une idée fin du coup. Parce que tu diras, si je mets 8 nœuds de cette taille-là, à 82 cents de l'heure, ça me coûte tant. Et là on est déjà en géologie où tu es un expert, où tu sais coder des jobs à pre-use. Et dans Amazon Machine Learning, on veut vraiment aller à l'autre extrémité du spectre. On dit non, on veut un truc super simple. On ne veut pas que les gens se posent des questions d'algorithme. On ne veut pas que les gens se posent des questions d'infra. On veut juste qu'ils uploadent leurs données, qu'ils sélectionnent ce qu'ils veulent prédire. Et c'est tout. Après on implique qu'ils puissent créer une application. Après, ça peut être intéressant de faire les deux en parallèle et puis de voir. Tu prends un out, tu codes ton truc, tu codes ta prédiction et puis tu la compares avec celle de l'Amazon Machine Learning. Quelque chose me dit que ça se rapproche. Est-ce qu'il y a d'autres questions ? Oui ? Oui, merci pour la question. C'est vrai qu'à chaque fois on me la pose et à chaque fois j'oublie de le dire et j'oublie de le mettre dans mes slides et j'oublie de modifier ma démo. C'est pas vrai que je le fasse pour la prochaine fois. Oui, je montre des requêtes simples parce que je suis obligé de faire des trucs un peu simples. S'il faut que j'explique le schéma en plus pendant 10 minutes, c'est un peu dur. Oui, bien sûr, on fait des jointures et d'ailleurs ça permet de rebondir sur la clé de distribution. Donc, souvenez-vous, la clé de distribution, c'est celle qui dit comment on shard les données entre les nœuds. Et donc, imaginons qu'on ait une table de référence qui soit hyper utilisée. Donc, dans mon cas, ça pourrait être la liste des 51, enfin, 56 États américains. D'accord ? Imagine que je fasse des jointures en permanence sur cette table-là. J'aurais envie qu'elle soit présente sur tous les nœuds, parce qu'en plus, si elle fait 56 lignes, l'overhead de la répliquation sur tous les nœuds pour que toute la jointure se fasse localement sans qu'il y ait de communication interne, ça vaut la peine. Donc on peut avoir une politique de distribution qui dit « tu mets la table sur tous les nœuds ». Voilà, donc typiquement sur les tables de référence, les tables de jointure, c'est ce qu'on aurait envie de faire. Et on s'en fiche de gaspiller 15 fois 56 lignes, d'accord ? Donc oui, bien sûr, on peut faire, je vais dire 99% du SQL Postgre, il y a une page spécifique dans la doc qui dit voilà ce qui est différent. Alors, il n'y a pas d'index, etc. Après, il y a quelques nuances. Mais dans l'ensemble, il n'y a pas de gros problèmes. Merci de m'avoir rappelé de... Je n'ai pas encore fait mon travail. Une autre question ? Je pense qu'ils ont fait. Oui ? Du coup, dans le deuxième outil qui nous a parlé, qui est sorti aujourd'hui, on a parlé d'un moteur qui était memory et on pouvait brancher de la data visualisation intégrée d'Amazon mais on peut aussi brancher apparemment des outils type tableau. Alors sur QuickSight c'est packagé. Je parle à l'instant T parce que peut-être qu'un jour ça changera, on ne sait jamais. Mais à l'instant T dans QuickSight, le moteur Spice, il est intégré avec la magnifique console web que vous avez vue. Il n'y a pas d'ouverture vers l'extérieur. En revanche, par exemple sur Redshift, on pourrait tout à fait connecter un tableau. Voilà, Redshift c'est ODBC, JDBC. C'est vrai ? Je crois que... Je vérifierai, mais il me semble, alors peut-être qu'il y a des partenariats en cours, à ma connaissance, pour l'instant, il n'y a pas d'accès externes à Spice, mais peut-être que je dis le bêtise. C'est possible, je vérifierai. Ça ne m'étonnerait pas qu'ils le fassent, parce que c'est ce que les gens vont dire, les gens vont dire, nous on utilise Tableau, et voilà. J'avoue que, n'ayant eu accès que ce matin, je ne suis certainement pas Je pense que les 10 minutes sont passées, tu vas avoir l'honneur de faire gagner le ebook. Il y en a qu'un ? Il y en a qu'un. Je cours vite. Je n'ai pas une main innocente. Je m'excuse auprès des 89 personnes qui vont être très déçues. Allez. Salma Oumy. Bravo. Ouais, j'ai fait gagner du fil. Applaudissements. Applaudissements. Du coup, tu viens nous voir et puis on va te donner un truc à la procédure pour télécharger ton idée de pitch.