Big Data battle sur AWS Redshift Athena EMR

Transcript

Bonjour à tous, nous revoilà pour le deuxième webinar de cet après-midi dédié au Big Data. Dans le premier webinar, nous avons fait une présentation générale du Big Data, de ses problématiques et des points techniques qui pouvaient vous aider à choisir les bonnes solutions, à choisir les bons services pour construire votre plateforme. Dans ce deuxième webinar, nous allons confronter quatre services AWS au même dataset et nous allons observer les résultats en direct et en discuter. Quelles sont les règles ? Les règles, je viens de le dire à l'instant, c'est le même dataset. Nous allons en parler plus en détail dans quelques minutes. Ce dataset, nous allons l'explorer avec les mêmes requêtes SQL pour les quatre back-ends. J'ai fait le choix explicite d'utiliser SQL parce que c'est évidemment le standard de fait pour les bases de données. C'est un langage que tout le monde connaît. C'est un langage qui est relativement facile à apprendre, y compris pour des gens qui n'ont pas nécessairement une formation technique, une formation d'ingénieur en informatique. Et évidemment, il y a beaucoup de gens qui utilisent SQL, y compris en dehors des équipes techniques. Donc j'ai fait le choix délibéré d'utiliser SQL pour essayer d'exposer les services dont je vais vous parler au plus grand nombre. La troisième règle, c'est que les données sont au même format. En l'occurrence, j'utilise un format en colonne, j'utilise le format Apache Parquet, qui sera lu à l'identique par les 4 back-ends. On va reparler un petit peu des formats en colonne dans quelques instants. La quatrième règle, c'est que les données sont au même endroit. Le dataset est dans S3, dans un bucket S3, qui sera accédé de manière identique par les différents back-ends. Et enfin la dernière règle, c'est que je n'ai procédé à aucune optimisation particulière sur les différents services. J'ai démarré les services, il n'y a pas d'optimisation, de ruse, je les utilise vraiment comme si j'étais un utilisateur un peu débutant qui connaissait SQL et qui avait envie d'explorer un jeu de données et de voir lequel de ces services pouvait être le plus adapté. Voilà les règles. Alors quels sont les quatre services dont nous allons parler aujourd'hui ? Nous allons parler de Dive, donc au sein d'EMR, Elastic Map Reduce. Nous allons parler de Spark, également au sein d'Elastic Map Reduce. Nous allons parler de Redshift Spectrum, qui est une évolution de Redshift qui a été annoncée il y a quelques semaines. Et nous allons parler d'Athéna. On va balayer rapidement ces quatre services pour se remettre en tête leurs grandes fonctionnalités, et que je vous explique la configuration précise que j'ai choisie, puis ensuite on fera les tests. Commençons donc par EMR. EMR c'est un service managé qui vous propose les outils de l'écosystème Hadoop. Donc Hadoop lui-même, Pig, Hive, Spark, etc. C'est un service qui a été lancé en avril 2009, ce qui paraît extrêmement lointain. Et donc précisément aujourd'hui, je vais utiliser Hive, qui est la base de données s'appuyant sur HDFS, dont la documentation est évidemment disponible en ligne. Et je vais utiliser HiveQL, qui n'est pas stricto sensu du SQL mais qui est ce qui s'en approche le plus dans cet environnement. En 2015, nous avons introduit Spark sur EMR et qui dans une de ses déclinaisons supporte le SQL, Spark SQL dont la documentation est également disponible en ligne. Donc je vais utiliser ces deux services en parallèle et déjà les comparer entre eux, puis on les comparera avec les deux autres. Combien coûte Amazon EMR ? EMR est un service d'infrastructure managé des instances qui sont lancées et qui ont un prix qui dépend de la taille de l'instance. Donc ma configuration ici, la configuration de mon cluster est la suivante : j'ai 20 nœuds C4 4XL, donc qui sont des machines relativement puissantes, pour un coût total d'environ 16 dollars de l'heure. C'est le prix on-demand qu'on pourrait évidemment optimiser en instance réservée ou en spot instance. Mais ici pour la démo, on va rester sur des choses simples. Donc voilà le cluster que j'ai choisi d'utiliser. Vous allez me dire, pourquoi 20 et pourquoi C4 4X large, pourquoi pas autre chose ? Tout simplement parce que c'est un cluster qui est déjà d'une taille respectable. C'est un cluster qui va disposer de beaucoup plus de RAM, en tout cas de beaucoup plus de RAM qui est nécessaire pour stocker, s'il en a envie, tout le dataset en RAM. Donc j'essaie de le mettre dans des conditions optimales. 20 nœuds avec 16 vCPU, ça fait une puissance de calcul qui est déjà très respectable. Le deuxième service qu'on va utiliser, c'est Amazon Athena, qui a été lancé à re:Invent. Athena, c'est un service qui vous permet de faire des requêtes SQL sur des données stockées dans S3. Il est basé sur le projet open source Presto que vous connaissez peut-être. C'est un service qui est entièrement managé, donc vous ne gérez absolument aucune infrastructure, un peu comme DynamoDB ou S3. Vous vous contentez d'utiliser le service, vous vous connectez à Athena et vous exécutez vos requêtes, et c'est tout. Donc aucune forme de gestion d'infrastructures, aucune forme de chargement de données ou de préparation de données, d'indexer, vraiment rien. On vous crée simplement une table dans Athena qui va correspondre au schéma des données qui sont dans S3, et c'est tout. Donc un create table qui prend moins d'une seconde, et vous pouvez requêter Athena. Athena coûte 5 dollars par terabyte scanné. Pour chaque requête, Athena va mesurer le volume de données qui a été parcouru par la requête et puis au prorata des 5 dollars par terabyte, calculer le coût de cette requête. Le troisième service qu'on va utiliser, c'est un service qui s'appelle Redshift Spectrum, qui est une évolution de Redshift. Redshift, dont on a déjà parlé, est le Data Warehouse d'AWS, un Data Warehouse relationnel qu'on peut utiliser en SQL, capable de scaler jusqu'au multi pétaoctets, mais qui s'appuie sur une architecture comparable à celle d'EMR. On crée un cluster avec des nœuds et on travaille avec le stockage et la puissance de calcul de ces nœuds. Mais avec Spectrum, maintenant vous pouvez étendre le pouvoir de Redshift au-delà des données qui sont stockées sur les disques locaux. Vous aurez, comme dans Athena, la capacité à exécuter des requêtes SQL sur des données qui sont dans S3. De la même manière que dans Athena, on verra les commandes tout à l'heure, vous allez créer une table externe qui correspond à des données dans S3 et vous allez pouvoir les requêter. Vous allez envoyer la requête au cluster Redshift, qui va l'optimiser, la découper et l'envoyer à une flotte de nœuds Spectrum qui sont complètement managés et complètement à l'extérieur du cluster. Donc finalement, lorsque vous utilisez Spectrum, vous vous servez du cluster Redshift comme point d'entrée. Éventuellement, vous utilisez des données qui sont stockées sur le cluster pour faire des jointures avec les données qui sont dans S3. Ici, ça sera pas le cas, vraiment je me servirai uniquement de données qui sont dans S3, mais vous avez finalement un peu le meilleur des deux mondes : la capacité à faire du requêtage hyper rapide, hyper optimisé sur des données locales, mais des datasets dont la taille dépend de la taille de votre cluster, et puis vous êtes aussi capable d'aller requêter et voir joindre des données hyper massives qui peuvent être hébergées dans S3. C'est un service qui est tout neuf, qui a été annoncé il y a quelques semaines. Le coût de Redshift est le coût habituel de Redshift, c'est-à-dire par instance par heure. Le coût de Spectrum est le même coût qu'Athena, donc 5 dollars par terabyte scanné. Ici, j'ai créé un cluster Redshift 2 avec quatre nœuds, les quatre nœuds les plus puissants. J'insiste sur le fait que ces nœuds là, finalement, ne serviront pas à grand chose puisque la table que je vais utiliser est 100% stockée dans S3 et donc elle sera analysée par la flotte de nœuds Spectrum qui sont vraiment une fois de plus en dehors du cluster Redshift. Néanmoins, le coût de ce cluster est un peu plus de 19$. J'ai essayé d'avoir un coût comparable avec le cluster EMR, parce que c'est souvent des systèmes, je ne sais pas s'ils rentrent en compétition, mais en tout cas ils peuvent être amenés à faire des tâches un petit peu similaires. Donc je me suis dit, voilà, pour 15-20 dollars par heure, ce qui est déjà une somme tout à fait honnête, quelle est la puissance de calcul dont je peux disposer dans EMR et quelle est la puissance de calcul dont je peux disposer dans Redshift ? Voilà les différents services que nous allons utiliser. Alors parlons quelques instants du dataset. Je vais utiliser un dataset qui s'appelle GDELT, ce qui est un acronyme un peu compliqué. Qu'est-ce que c'est que ce dataset ? C'est un dataset qui référence toutes les activités politiques et diplomatiques dans le monde, sur la base d'articles de presse et d'articles web. C'est un dataset intéressant parce qu'il remonte à 1979. Il est désormais mis à jour quotidiennement. Tous les jours, vous avez un nouveau fichier qui contient les dernières actualités, les dernières nouveautés. C'est un dataset au format CSV, qui est relativement complexe, 58 colonnes, et qui contient tout un tas d'informations sur les acteurs, donc qui a dit quoi, qui a dit quoi sur qui, des informations de géolocalisation, des informations de catégories, etc. On verra un petit exemple tout à l'heure, vous verrez, 58 colonnes, c'est quand même déjà relativement complexe. Ce dataset est en fait hébergé parmi les datasets publics d'AWS. Si vous n'avez jamais regardé cette URL, allez-y, aws.amazon.com. J'ai également écrit un petit article de blog pour expliquer un petit peu le fonctionnement du dataset et comment j'en étais arrivé à partir du dataset et de l'aspect à créer la table, les colonnes, etc. Je n'entrerai pas trop dans les détails aujourd'hui, mais vous trouverez plus d'informations sur mon blog. À l'instant T, il y a 1612 fichiers. Demain, 1613, et après-demain, 1614. Il y a une taille totale de dataset d'environ 150 gigaoctets. Je vais tout insérer dans une seule table. Il y a quelques petites tables de référence avec les codes des pays, les codes d'événements, etc., mais c'est vraiment juste des tables de référence. La table principale a 58 colonnes et environ 450 millions de lignes. Donc quand même un dataset pas forcément ultra volumineux, mais une grosse table avec beaucoup de colonnes. Ce dataset est dans un format CSV qui n'est pas le format le plus performant. Pour des raisons de brièveté de la démonstration et pour vous montrer comment le faire, je voulais vous parler quelques instants de la conversion vers des formats plus performants. Les formats en question sont les formats en colonne, on en a deux aujourd'hui qui sont supportés par Athena et Hive : Parquet, qui est un format en colonne de Cloudera, et ORC, qui est un format en colonne d'Hortonworks. Sauf erreur de ma part, ORC n'est pas encore supporté par Redshift Spectrum, et donc c'est pour ça que j'ai choisi de garder Parquet. L'avantage des formats en colonnes, c'est que, évidemment, ici on voit une table avec 58 colonnes. Quand je vais requêter, j'ai absolument pas envie d'avoir les 58 colonnes, en tout cas je vais sûrement pas les utiliser dans chaque requête. Je vais utiliser quelques colonnes. Si on stocke ça de manière traditionnelle dans un format ligne comme dans une base de données classique, on se retrouve à lire lorsqu'on fait les requêtes, même si j'ai besoin de deux colonnes, je vais me retrouver à lire les 58 colonnes. Donc je fais beaucoup d'entrées/sorties qui sont complètement inutiles pour mon résultat, qui me font perdre du temps et qui me coûtent de l'argent puisque pour certains de ces services, la tarification se fait au volume de données scannées. L'avantage des formats en colonne, comme leur nom l'indique, c'est qu'on va écrire les données en colonne. Donc sur un bloc disque donné, on ne va avoir que les données d'une colonne bien précise. Et donc si dans ma requête, j'ai besoin de 3 ou 4 colonnes, le back-end va se contenter de lire les blocs disque qui correspondent aux colonnes que je lui ai demandé d'explorer. Et évidemment, ça va réduire de manière très spectaculaire le volume de données lu. Si j'envoie une requête qui fait un full scan sur le dataset en CSV, je lis tout, je lis 136 ou quelques gigas de données. Ça va me coûter 0.13 cent. N'oubliez pas, 5 dollars par teraoctet pour Athena et Spectrum. Si je convertis ces données dans un format Parquet et qu'en plus j'applique de la compression sur ces données, la même requête ne va plus nécessiter que la lecture de deux et quelques gigas pour un coût de 10e de cent. On a divisé le coût de la requête par pas tout à fait par 100, mais au moins par 50 ou 60. Et les performances vont s'en ressentir. Voilà pourquoi on va utiliser le format Parquet aujourd'hui, mais ça ne changera pas la donne. J'ai fait les mêmes tests sur les back-ends avec les données en CSV, on obtient des résultats comparables. Bon, assez parlé, je pense que l'heure est venue de confronter nos back-ends à ce dataset et de voir ce que ça donne. J'ai préparé un petit tableau pour noter les résultats au fur et à mesure. Donc nos back-ends et puis les quatre requêtes qu'on exécutera sur chacun de ces back-ends, et on notera le temps au fur et à mesure. Il y a un petit cas particulier à la fin, mais j'en parlerai tout à l'heure. On va mettre ça de côté pour l'instant. On va peut-être jeter un petit coup d'œil très vite aux différentes configurations. On va commencer par EMR, on va les prendre dans le même ordre que tout à l'heure. Donc ça c'est le cluster que j'ai créé. On voit bien qu'on a ici un master node plus 19 autres nœuds, donc on a bien 20 nœuds. On a installé Hive, on a installé Spark, on a tout ce qu'il faut. Les 20 nœuds sont up, c'est une bonne nouvelle. Ils ont 16 CPU chacun. C'est bien ce qu'on s'attendait à voir. On regardera un peu les graphes tout à l'heure. C'est pas le cœur de la discussion, mais c'est rigolo de voir est-ce que le cluster va vraiment travailler très fort ou est-ce qu'on l'a surdimensionné. Sur ce cluster, j'ai Spark et j'ai Hive, comme je l'ai dit. Donc j'interagirai avec Hive via un notebook sur Hue. C'est aussi l'occasion de vous montrer quelques outils un peu différents et de vous montrer un peu les différentes façons d'accéder au back-end. Donc voilà, ça c'est l'interface graphique d'Hadoop qui s'appelle Hue et qui permet de définir des petits notebooks comme ça. C'est sympa. Voilà, donc là j'ai toutes mes requêtes, on va en parler un peu plus tout à l'heure. Pour Spark, on va faire de la ligne de commande histoire de varier un peu les plaisirs. Donc j'ai ici une connexion sur mon masternode EMR, j'ai préparé mon code avec les requêtes SQL qui correspondent exactement à celles qui sont ici, et on les exécutera au fil de l'eau. Ensuite, ici j'ai Spectrum, ça me permet de vous montrer comment on interagit. Je suis connecté sur mon cluster qui s'appelle Redshift XL. Donc j'ai créé déjà une table. Notez bien le External Table qui prouve bien que les données ne sont pas locales au cluster. Voilà les fameuses 58 colonnes. Et puis le point important, c'est de dire que, évidemment, ce dataset, il est dans S3. Voilà, j'ai créé une table au format Parquet que j'ai initialisée. Les données sont dans S3. Donc, c'est à partir de cet endroit-là que je vais vraiment aller les chercher. Voilà, j'ai mes petites tables de référence ici qui contiennent les codes des pays, etc. Et puis, voilà, en dessous, j'ai mes vraies requêtes qu'on va exécuter, et qui sont exactement les mêmes. On peut regarder, on est bien sur les mêmes requêtes, il n'y a pas de différence. On les regardera après. Et puis en dernier lieu, oui, j'ai oublié de mentionner cet outil que j'aime beaucoup, je vais faire un peu de pub. Pour se connecter à Redshift, c'est un outil open source qui s'appelle Postico. Voilà, Postico, je vous recommande, qui est vraiment super si vous travaillez beaucoup avec Postgre et en l'occurrence avec Redshift qui utilise le protocole SQL de Postgre. C'est vraiment un très bon outil. Voilà, donc Postico chaudement recommandé. Et pour Athena, j'utilise SQL Workbench, qui est un bon outil aussi pour toutes les connexions sur les bases de données qui ont des drivers JDBC. Ça marche bien. Voilà, donc ici je me suis déjà connecté, et là aussi une fois de plus je vois un petit peu ma configuration. On va regarder justement les requêtes, les 4 fameuses requêtes, et puis ensuite on va commencer à les exécuter. On va commencer doucement. La première requête que je vais exécuter, je vais peut-être vous montrer 10 événements d'abord. Histoire qu'on voie la vilaine tête que ça peut avoir. Donc voilà, 10 événements au hasard. 58 colonnes, elles ne sont pas toutes pleines. On va trouver des trucs plus ou moins... Il y a évidemment des timestamps, il y a des codes pour codifier les événements, des acteurs donc qui est concerné par la nouvelle, etc. Il y a pas mal d'infos. Le code des événements, donc qu'est-ce qui s'est passé. Voilà, tout ça va renvoyer à mes petites tables externes des infos de géolocalisation. Un dataset un peu trapu, un peu trapu en l'état, pas très très lisible. Donc la première requête qu'on va exécuter, c'est on va simplement compter les événements. Donc là, on fait un full scan, on fait un compte étoile sur la table. On va le faire partitionner pour que ça aille un petit peu plus vite. Première requête. Ensuite, la deuxième requête qu'on va exécuter, c'est celle-ci qui est un petit peu plus compliquée. Donc cette requête-là, elle va nous sortir les 10 événements les plus fréquents. Donc, le code, ça peut être négocier, recevoir un chef d'État, etc. Il y a à peu près 300 codes différents. Donc, sur l'ensemble du dataset, on va chercher les 10 catégories les plus fréquentes. OK ? Ensuite, on va exécuter cette requête. Donc on va compter par année le nombre d'événements qui concernent Barack Obama. J'ai pris Barack Obama au hasard. J'aurais pu prendre n'importe qui, mais je me suis dit qu'il y en aurait pas mal sur Barack Obama. Donc voilà, ça ferait travailler un peu le système. Donc troisième requête. Et puis dernière requête, on cherchera par catégorie les plus fréquentes tous les événements qui concernent Obama et Poutine. Là aussi, je me suis dit qu'il y en aurait pas mal. En bonus sur Hive et sur ce parc qui dispose donc de stockage local, on fera la même requête et au lieu de la faire dans S3, cette fois on la fera sur la même table Parquet mais stockée localement sur le cluster, pour voir s'il y a une grosse différence. Bon, alors c'est parti, on va essayer de les faire dans l'ordre. On va commencer par Hive, on va les lancer en parallèle sur les différents systèmes. Donc parquet Hive, c'est parti. Spectrum, voilà, Spectrum parquet, c'est parti. Il faut que je me reconnecte, voilà, ça y est. Redshift, Redshift, Redshift, on s'est en haut, voilà, on va essayer de le faire dans l'ordre et la discipline. Redshift parquet, voilà. Alors je vais attendre que Hive soit terminée parce que si je lance Spark, je vais pénaliser. On va noter les résultats. Alors Athena 4 secondes 22, on va mettre les décimales, on va être précis. Spectrum 3.2. Donc là on a fait un compte sur 450 millions et quelques de lignes. Ah là là, côté Hive ça tourne encore. On est à 1 minute 14, ça continue 1 minute 20. Pendant que ça se termine, je vais vous montrer le code. Donc ici j'ai défini une petite fonction qui me permet de mesurer le temps d'exécution. Je prends le SQL contexte et puis vous voyez j'exécute ma requête SQL. Voilà, et je regarde le temps que ça a pris. On va attendre que Hive soit terminée si elle veut bien terminer. Je pense que les pronostics ne font à peu près aucune surprise. Vous voyez, on est sur un cluster qui est de taille importante et on est déjà à deux minutes. On va regarder ce qui se passe un peu ici. Là, on voit que ça travaille, mais ce n'est pas du tout au taquet. Donc voilà, on voit que le pic CPU n'est pas du tout terrifiant. Le pic réseau non plus. Bon, ça travaille, mais on n'est pas sur des charges phénoménales. Et c'est toujours pas terminé. C'est effrayant. Je pense qu'on fera une petite pause au montage. Nous avons fait une petite pause pour vous épargner le temps d'attente, et donc le résultat est que cette requête sur Hive a pris 245 secondes, ce qui est vraiment particulièrement lent, encore plus lent que lors de mes tests. Et histoire de gagner un petit peu de temps, on a fait également la requête suivante, donc les 10 premières catégories, et ça a pris sur Hive 189 secondes. Donc on va lancer maintenant la même requête sur les autres. On va lancer donc sur Spark. Très bien. On va le lancer sur Spectrum. Ah oui, il faut que je prenne toute la requête. Voilà. Très bien. Ah, il faut que je me reconnecte. Voilà. On va la lancer sur Athena. C'est bien en format Parquet. Ouais, c'est bon. Alors, Spectrum 4,2. Athena 5,1 et Spark 23,97. Allez, on enchaîne. Donc maintenant on va compter les 10 événements, pardon, les événements d'Obama par année. Attention, on va commencer par Hive qui est le plus lent. Donc les événements d'Obama par année, la voilà. C'est bien du Parquet, c'est parti. Ok, on va faire Spectrum. On va faire Réalisation. Alors, Spectrum 3.2. Alors, on voit le résultat, le nombre d'événements. Donc, sur Athena, on voit que la requête prend 8.41. Alors 8.41. Est-ce que Hive s'est terminé ? Espérons-le. Alors Hive s'est terminé en 30 secondes 73. On revient à des valeurs un peu plus correctes. Et on va lancer Spark. Spark. Alors, est-ce que Spark va aller plus vite que Hive sur ce coup-là ? On peut l'espérer. 30 secondes. Regardez. Là, manifestement, sur cette requête-là, il s'est passé quelque chose d'assez anormal sur le cluster. Mais allez savoir quoi ! Allez Spark, au travail. Le suspense est insoutenable. Est-ce que ça fait moins de 30 secondes ? Je pense que non. Je pense que non. Pense qu'on est plus lent alors au 29 10 à l'envoyer. Bon, à peine égalité. Alors la dernière, donc maintenant et donc on voit on voit les résultats là aussi vous voyez que ce sont les mêmes 60 événements en 2005. Voilà, 60 événements, je ne triche pas, on fait bien la même chose. Allez, dernière requête. Donc les événements... Les événements Obama-Poutine par catégorie. Allez, on va lancer celle-là. Paf. On va lancer Spectrum. Celle-là est plus longue. C'est bon. On va lancer Redshift. Pardon, pas Redshift, Athena, excusez-moi. Alors, Spectrum 5.1. Oui, celle-là, pardon. Athena 5.7. Hive, que fais-tu Hive ? Tu calcules. On va jeter un petit œil. Donc on voit qu'on dépasse jamais finalement 20% de CPU, donc on n'est pas du tout, même si des requêtes compliquées sur tout le dataset, on n'est pas du tout limité par le CPU. Donc il y a un autre facteur limitant. La charge du cluster est finalement assez faible, le débit réseau n'est pas non plus gigantesque, on voit la charge agrégée des nœuds, elle n'est pas phénoménale. Donc bon, le cluster est surdimensionné. Donc les performances relativement mauvaises de Hive doivent s'expliquer par autre chose. Où est-ce qu'on en est ? Ça tourne toujours. Voilà, on a le résultat. Ça a mis 50-38. Voilà. Et donc, on voit les résultats. Donc, la catégorie la plus fréquente, c'est consulter, négocier, etc. Discuter par téléphone. Bon, c'est rassurant. Pour l'anecdote, dans les codes des événements, il y a guerre thermonucléaire, etc. Donc, bon, j'ai vérifié, je vous confirme qu'il y a zéro événement de ce type depuis 1979, ce qui est plutôt une bonne nouvelle. Donc 5038, et puis on va finir ici. Qu'est-ce qui me crache du stack Java alors on va finir avec Spark. Donc est-ce que Hive va être battu 50 secondes ? Alors en attendant que Spark fasse cette dernière requête, on voit clairement les résultats. On voit que Spectrum est en tête, même devant Athena. Je m'interroge sur la raison de cette domination de Spectrum. Donc il faut croire que Spectrum scale en plus fort et encore plus optimisé qu'Athena. Alors Athena est basé sur Presto qui est une plateforme open source. Spectrum est un service d'Amazon, d'AWS. Donc il est possible que le fait de ne pas être basé sur un produit ouvert, ça laisse peut-être les mains plus libres aux équipes de développement pour optimiser encore au-delà de ce que le produit open source peut faire. Donc voilà, Athena et Spectrum sont vraiment deux produits complètement différents. Spectrum n'est pas un Presto optimisé, c'est vraiment un produit différent. Voilà, c'est une hypothèse, j'essaierai d'en savoir plus. 23 secondes 12. Donc on voit une domination massive de Spectrum, ce qui est d'autant plus impressionnant que le scaling se fait complètement automatiquement. Je passe par mon cluster Redshift certes, mais finalement il sert de peu de passe-plat dans cette histoire, il fait pas grand chose, c'est vraiment les nœuds Spectrum qui travaillent. Bon, Athena s'en sort quand même très très bien. Donc Athena reste très pertinent pour l'utilisation ad hoc si vous n'avez pas besoin d'avoir un cluster Redshift pour la BI, bien vous pouvez utiliser Athena au jour le jour de manière bien plus économique puisque vous n'avez que les coûts de requête, alors que sur Redshift Spectrum, vous avez le coût de Redshift qui est un coût par instance par heure, etc., plus le coût de Spectrum. Si vous avez déjà un cluster Redshift, vous pouvez bénéficier automatiquement des performances de Spectrum. Si vous n'avez pas de cluster Redshift et vous n'avez pas besoin d'en avoir un, vous pouvez utiliser Athena et avoir des perfs qui sont tout à fait comparables. Bon, alors après on voit que Hive montre son âge, la première requête est réellement catastrophique, elle est peut-être aberrante, mais on voit que même le reste est quand même le facteur entre Redshift Athena d'un côté et Hive de l'autre est quand même important, on est quasiment sur x10 quand ce n'est pas plus. Bon, et Spark dans tout ça, alors Spark s'en sort mieux sur les premières requêtes en particulier, mais on est quand même sur des temps qui restent très supérieurs à Spectrum. Alors il est vrai que je ne mets pas Spark dans un contexte particulièrement sympathique parce qu'une des grandes forces de Spark c'est de travailler in memory. Donc effectivement une fois que j'ai chargé le dataset dans Spark et qu'il est en RAM, je peux continuer à travailler avec les data frames, je peux continuer à faire du lazy evaluation, je peux continuer à faire plein de choses. Donc effectivement si on devait travailler de manière très récurrente avec le dataset, il y aurait un avantage à utiliser Spark, passer les premières requêtes et passer le chargement en RAM, après les choses iraient évidemment beaucoup plus vite. Mais là je voulais vraiment comparer sur des requêtes initiales, tous les systèmes étaient froids, il n'y avait pas de cache, il n'y avait rien du tout. Alors, on peut quand même s'interroger sur la raison de ces deux-là. Et pour finir, ce que je vous propose, c'est de réexécuter cette dernière requête, mais sur un HDFS local. Donc le dataset, j'ai copié le dataset sur le cluster et de le réexécuter sur HDFS. Hive et sur Spark et de voir s'il y a une grosse différence. Alors allons-y déjà pour Hive. Donc on était à 50 secondes. On va voir. Est-ce que le fait d'avoir HDFS plutôt qu'S3, les données restent en format Parquet ? Est-ce que la localité du file system fait une grosse différence ? Alors on finit en 24, 54. Donc on divise par 2. On divise par 2, ce n'est pas négligeable. Et est-ce qu'on observe la même chose sur Spark ? Donc idem, même requête mais sur HDFS. Donc s'il y a une logique, on devrait tomber à un ami 23, on devrait être capable de la faire peut-être en 12-13. Si ce facteur 2 se vérifie. On va voir ça tout de suite. Ça paraît un peu long. Alors, on a fait 20 secondes. Donc, vous voyez ? Autant sur Hive, c'est un test très partiel, mais on voit quand même une différence assez nette entre le local et le S3. Autant sur Spark, ça ne saute pas aux yeux. Je ne sais pas ce qu'on peut en tirer comme conclusion. Il ne semble pas que la localité des données joue beaucoup plus sur cette histoire. Voilà les chiffres. Alors écoutez, ce que je veux vous inciter à faire, c'est évidemment de refaire vos propres tests avec vos propres datasets et puis si vous voulez les partager avec moi, n'hésitez pas à m'envoyer un mail ou m'envoyer un tweet. Ça m'intéresse de voir quelles sont les conclusions que vous allez tirer. L'objectif n'est pas de dire qu'il faut jeter Hive à la poubelle et que Spectrum est le meilleur service du monde. L'objectif, c'est vraiment de vous montrer qu'au fil des évolutions, au fil des années, il y a quand même des services de plus en plus performants qui sortent. Entre Hive et Spark, on voit déjà des différences importantes. Et donc, en fonction des cas d'usage, en fonction de vos applications, vous pouvez arriver à des améliorations spectaculaires du temps de réponse. Quand on passe de 50 secondes à 5 secondes sur cette requête, 5 secondes c'est le temps de cliquer et d'attendre le résultat à peine, 50 secondes c'est une minute à rien faire devant son écran. Si vous faites ça toute la journée, il y a évidemment une productivité qui n'est pas la même et potentiellement un énervement qui n'est pas le même. Pour des datasets très volumineux, vous voyez que c'est pareil. Même si ce chiffre-là paraît un peu étonnant et élevé, même si on le divise par deux, on arrive quand même à un ratio x20, x30 entre Hive et des services plus récents. Donc sur des gros datasets qui vont tourner des heures, voire des jours, pourquoi ne pas essayer Spectrum ou Athena pour diviser vos temps d'attente de manière importante. Le dernier point, si je voulais juste revenir dessus, c'est le coût. De ce point de vue-là, finalement, je dirais, il y a Hive qui est sans doute le plus coûteux puisque vous avez un cluster de 20 nœuds, mais peut-être que vous avez plus chez vous, qui vous coûte 20 fois le tarif horaire x 24. Certes, on peut optimiser avec les instances réservées et les instances spot, mais c'est quand même du paiement à l'heure. Et si le cluster n'est pas 100% utilisé, bien sûr, c'est bien rare qu'un cluster Hadoop soit à 100% CPU toute la journée. Généralement, il y a plutôt des pics, des creux, etc. Pas hyper optimisé donc économiquement Hadoop voire Spark ne sont pas forcément les choix les plus intéressants. Athena de ce point de vue-là a un très gros avantage en étant purement facturé au volume de données scannées. Redshift est un peu entre les deux donc si vous aviez déjà du Redshift, ruez-vous sur Spectrum. Si vous n'avez pas de Redshift et que vous voulez faire du requêtage ad hoc, bien choisissez plutôt Athena. Si vous utilisez Hive ou Spark, c'est très bien, vous pouvez continuer à faire ça, mais sachez qu'il existe des nouveaux services qui peuvent convenir à vos applications et qui peuvent diviser vos temps d'attente par 10 ou par 20 selon les cas et rendre le travail interactif beaucoup plus envisageable. Voilà ce que je voulais vous dire aujourd'hui. J'espère que ce webinar un peu différent vous a intéressé. On va continuer à affiner, on va continuer à travailler ces sujets et puis on aura de nouveaux services. Peut-être que cette année, on aura l'occasion de refaire un nouveau benchmark, peut-être sur d'autres datasets aussi. Voilà, je vous remercie beaucoup de nous avoir écoutés. Une fois de plus, on est en différé exceptionnellement ce mois-ci. Si tout va bien, je serai connecté au moment où vous entendez ceci pour répondre à vos questions. Donc n'hésitez pas à les poser. Et dans tous les cas, je vous donne rendez-vous évidemment le mois prochain, fin juin, pour le Summit AWS, le 27 juin, au Carousel du Louvre. Les inscriptions sont ouvertes. Venez découvrir le programme. On est en train de le publier. Il va être super. On a de belles keynotes, on a de belles sessions techniques, business, etc. Et on espère vous voir nombreux. Évidemment, on sera à peu près tous présents là-bas pour vous accueillir. Et puis, bien sûr, il y a aussi des webinars en juin, on aura l'occasion d'en reparler. Voilà, merci beaucoup, merci à Hugo pour la logistique sans faille. C'est Hugo qui diffusera tout ça le 30 mai. Merci beaucoup et à très bientôt. Au revoir.