Les mardis du cloud le Big Data

Transcript

Nous allons différer les webinaires avec l'aide d'Hugo. Vous les verrez donc en différé car je suis en déplacement à cette date et il me sera impossible d'assurer les webinaires en direct. J'essaierai néanmoins de me connecter pour les questions-réponses, mais je ne peux pas vous faire de promesses. J'essaierai vraiment d'être là au moins pour les questions. Très bien, aujourd'hui nous allons parler de big data, un sujet récurrent chez AWS et chez nos clients. Nous aborderons un ensemble de sujets et de services qui, je l'espère, vous aideront à y voir plus clair dans l'architecture Big Data que vous pouvez bâtir sur AWS, et surtout dans les choix que vous allez être amenés à faire, car vous verrez qu'il y a vraiment un grand nombre de services et de compétences. Nous commencerons rapidement par parler des quelques challenges du Big Data. Nous discuterons des principes d'architecture, puis nous balayerons l'ensemble des services et des technologies disponibles sur AWS pour construire des plateformes Big Data, en insistant bien sur les cas d'usage respectifs de ces différentes technologies. Enfin, nous examinerons quelques architectures de référence et quelques patterns que nous voyons fréquemment chez nos clients. Le big data n'est pas vraiment un sujet neuf maintenant, c'est un sujet qui a émergé il y a presque une dizaine d'années dans les entreprises. Ce qui différencie le big data des traitements de données habituels, ce sont essentiellement trois choses. C'est avant tout le volume, la quantité de données qu'on est amené à gérer. C'est le "big" dans Big Data. La vélocité avec laquelle ces données arrivent, c'est-à-dire le taux d'accroissement, la quantité de données supplémentaires que vous êtes amené à gérer chaque jour, chaque semaine. On n'est pas sur des datasets à très faible croissance, on est généralement sur des données liées, par exemple, au trafic web ou au trafic mobile de vos plateformes, et donc si ce trafic augmente fortement, la quantité de données augmente également fortement. L'autre point qui différencie le big data des traitements de données habituels, c'est aussi la variété des formats. Lorsqu'on travaille avec de la donnée classique, on est généralement avec de la donnée structurée, qu'on va stocker dans des bases relationnelles, avec un schéma bien défini, etc. Lorsqu'on travaille en Big Data, on se retrouve avec tout type de données. On peut avoir des logs web, des données structurées de base de données, des données JSON, toutes sortes de choses, et donc il faut des systèmes capables de s'adapter à cette variété. Dans la façon dont on traite ces données, il y a eu également beaucoup d'évolution depuis quelques années. Au début, on faisait du traitement batch. Les premières applications Hadoop, c'était du batch. On faisait tourner des traitements toutes les 4, 8, 24 heures sur des données, puis on extrayait les résultats. Progressivement, on est arrivé à vouloir traiter des flux de données pour agir en temps réel sur du trafic utilisateur, sur des événements externes. Aujourd'hui, la tendance va vers la collecte et l'analyse des données, mais aussi vers la prise de décision, l'utilisation de modèles prédictifs pour agir sur les données reçues, prendre des décisions en fonction des données reçues, et utiliser en permanence les données reçues pour enrichir les modèles. On est vraiment loin des débuts du big data où on se contentait de faire une agrégation, un traitement toutes les 8 heures. On est maintenant dans le temps réel et dans l'intelligence. Il y a également eu une évolution sur les services cloud. Au début du cloud, c'était les machines virtuelles. On démarrait un serveur, certes virtuel, mais avec une utilisation proche d'un serveur physique, avec la nécessité de l'administrer, de le patcher, de gérer le scaling, la capacité, etc. Progressivement, chez AWS, on a vu émerger des services managés, des services de plus haut niveau qui vous déchargent de l'infrastructure, vous permettant de vous concentrer sur la résolution de votre problème, des services comme S3, DynamoDB, RDS, etc. Depuis quelques années, sur AWS, on trouve aussi des services type serverless, des architectures serverless, où l'infrastructure est devenue complètement transparente, invisible pour les développeurs. Vous vous concentrez sur l'application, les workflows, sans tâches d'infrastructure. Des services comme Lambda, Kinesis, Athena, dont on parlera plus tard, sont dans ce schéma. Le Big Data, c'est une quantité d'outils impressionnante, et plus le temps passe, plus le nombre d'outils augmente. On a commencé avec Hadoop et son écosystème, Hive, Pig, etc., puis tout cela s'est enrichi avec Spark, d'autres outils, du NoSQL, du Machine Learning, etc. On a une quantité d'outils open source, d'outils tiers très importante, ainsi qu'un nombre important de services AWS. La question qu'on se pose souvent est : comment s'y retrouver avec ces dizaines de possibilités et les centaines et milliers de combinaisons qu'elles induisent ? Comment choisir pour construire notre plateforme ? Dans cette session, c'est vraiment à cette question qu'on va répondre. Comment naviguer ? Y a-t-il une architecture de référence pour faire du big data ? Non seulement il y en a une, mais il y en a plusieurs, que nous allons voir. Quels outils utiliser ? Ils dépendent du cas d'usage et de la problématique à laquelle vous vous attaquez. Comment s'y mettre ? Pourquoi choisir une solution plutôt qu'une autre ? Comment justifier que ces outils sont les bons pour le problème que vous résolvez ? Les grands principes que nous allons étudier aujourd'hui peuvent se résumer ainsi : comment découpler les traitements, comment organiser nos traitements Big Data avec des étapes très claires et des services très découplés, ce qui nous permettra de scaler les choses de manière indépendante. Quels outils choisir ? Comment utiliser les services managés et les architectures serverless pour simplifier la vie ? Comment stocker les données ? Faut-il garder toutes les données brutes ? Les transformer ? Agir directement dessus ou pas ? Comment contrôler les coûts ? Comment ajouter de l'IA et du machine learning ? La vision la plus courante du big data chez nos clients est un pipeline où, à l'entrée, on utilise des données pour travailler sur une question métier ou technique, et à la sortie, on veut des réponses. À l'intérieur de ce pipeline, on trouve quatre grandes étapes : la collecte, le stockage, le traitement et l'analyse des données, et la consommation des données. Les grandes propriétés de ce pipeline sont la latence, le débit, et le coût. La latence, c'est le temps qu'il faut pour obtenir une réponse après avoir envoyé les données. Le débit, c'est la quantité de données envoyées dans le pipeline et la scalabilité qu'on peut atteindre. Le coût, c'est le coût associé au pipeline. Ces trois paramètres sont essentiels tout au long de la discussion. Le paramètre le plus important qui dicte un grand nombre de choix est la "température" de vos données. S'agit-il de données froides, destinées à être archivées et requêtées occasionnellement, ou de données de streaming, en temps réel, sur lesquelles vous voulez des réponses presque instantanées ? Dans les architectures de nos clients, on voit vraiment cette distinction. Si on précise ce qu'on entend par "température", les attributs importants sont le volume, la taille unitaire d'un item, la latence associée au traitement des données, la durabilité, le taux de requêtage, et le coût. Aux deux extrêmes, on a des données très chaudes, généralement en petit volume, très granulaires, auxquelles on veut accéder instantanément, peut-être en millisecondes, et que l'on requête en permanence. Ces données peuvent être non structurées et vivre dans des caches ou dans DynamoDB. Elles sont essentielles au fonctionnement de votre plateforme, et vous pouvez justifier un coût de stockage élevé. À l'autre extrémité, on a d'immenses quantités de données, peut-être des pétaoctets d'archives de logs très volumineux, auxquels on accède rarement mais qu'il faut garder extrêmement longtemps pour des raisons de conformité, avec un coût de stockage le plus faible possible. Au milieu, on trouve toutes les combinaisons possibles. Commençons par parler de la phase de collecte. La phase de collecte se caractérise par le type des données que vous collectez. Vous aurez des données issues d'applications, d'applis web, d'applis mobiles, ou d'applis hébergées dans un data center physique. Ce sont des données extrêmement structurées, provenant peut-être de bases de données, des données transactionnelles. Vous pouvez aussi avoir des données de type fichier, des logs ou des fichiers importés via des mécanismes de migration, en quantité plus faible mais en taille plus importante. Enfin, vous pouvez avoir des données de type flux, venant d'applications ou d'applications IoT, que vous voudrez traiter de manière réactive. En fonction de ces types de données, vous devrez adapter la technique de stockage. Reprenons nos trois catégories : les données transactionnelles, structurées, seront insérées dans des bases de données SQL si elles ont un schéma très défini. Si les données sont semi-structurées ou faiblement structurées, comme du JSON, elles seront plutôt stockées dans une base NoSQL avec un schéma flexible et une scalabilité supérieure. Pour des données très chaudes et vitales, vous pouvez les stocker dans des caches pour les meilleures performances. Lorsqu'on travaille avec des fichiers, on a tendance à les empiler dans un système de fichiers ou dans un stockage objet comme S3. Pour les flux, il nous faut un outil dédié à la réception et au stockage de flux. Si on parle de flux, les grandes technologies que nous voyons chez nos clients sont Kafka, un projet open source pour collecter et router des flux de données de manière distribuée. Sur AWS, on peut utiliser Kafka en installant des clusters Kafka dans EC2 et en les gérant soi-même, ce qui est une charge de travail importante. Pour une solution managée, on peut utiliser Kinesis, un système de gestion de flux ultra-scalable, complètement managé, sans tâches d'infrastructure. Kinesis Streams est l'outil de bas niveau, permettant une manipulation fine du stream. Firehose est une abstraction de plus haut niveau pour déposer les flux dans S3, Redshift, et d'autres destinations. Kinesis Video Streams, lancé à ReInvent, permet de recevoir des flux vidéo et de les router vers des services d'analyse. L'avantage de gérer des flux avec des outils spécifiques est de séparer les producteurs des consommateurs. C'est la seule façon de scaler une plateforme, en garantissant que le volume de données envoyé par les producteurs peut être encaissé et stocké, puis consommé par des consommateurs, quel que soit leur nombre ou leur disponibilité. Kinesis maintient l'ordre des messages, une propriété importante. SQS, un service plus ancien, est destiné au passage de messages entre applications, mais ne garantit pas l'ordre des messages par défaut, sauf en FIFO. Il ne permet pas de consommation en parallèle et n'atteint pas les mêmes niveaux de scalabilité que Kinesis. On réserve donc SQS au passage de messages traditionnel. Pour le stockage de fichiers, la solution centrale est S3, le stockage objet sur AWS, avec une durabilité de 11,9, ce qui signifie que si vous aviez 100 milliards d'objets dans S3, vous en perdriez peut-être un par an. Vous avez de la sécurité pour les données en transit avec SSL et pour les données au repos avec KMS. S3 est l'endroit où vous devez stocker toutes vos données. Vous pouvez également utiliser HDFS si vous êtes un gros utilisateur de Hadoop, en créant des clusters EMR pour stocker vos données. L'inconvénient est que vous couplez la capacité de stockage avec la capacité de calcul du cluster. Il est préférable d'utiliser S3 et le connecteur S3 sur EMR pour accéder aux données. Pour les données transactionnelles, si elles sont très structurées, vous utiliserez une base de données relationnelle et un service comme RDS. Si les données sont moins structurées ou semi-structurées en JSON, vous pouvez utiliser DynamoDB, avec la possibilité d'ajouter un accélérateur DynamoDB pour des temps de réponse en microsecondes. Vous pouvez aussi utiliser Elastic Cache, qui supporte Memcached ou Redis. Il est important de ne pas utiliser un seul système pour tout faire. Il faut utiliser le bon outil pour chaque cas d'usage, en spécialisant les back-ends en fonction de l'application. Une fois de plus, l'utilisation d'S3 comme point central de stockage des données brutes est un pattern courant chez nos clients. On stocke ces données dans leur état brut pour pouvoir les réexplorer et appliquer de nouveaux traitements à l'avenir. On utilise des vues matérialisées, des transformations de ces données brutes projetées vers d'autres back-ends comme Elastic Cache, Cloud Search, ou RDS. Il est crucial de garder les données brutes pour garantir la flexibilité future. Le type de stockage dépend de la structure des données, de la fréquence d'accès, de la température des données, et du coût associé. En fonction du cas d'usage, vous devez faire une analyse pour choisir le bon service. Si vous avez des données à schéma fixe, vous opterez probablement pour SQL. Si le schéma est faible ou inexistant, vous choisirez NoSQL. Si vous avez besoin de requêtes complexes, vous irez vers SQL. Si des opérations put-get suffisent, des caches ou DynamoDB peuvent être suffisants. Sur ce schéma, on voit que pour des données peu structurées, des logs, des backups, des archives, auxquels on accède rarement, Glacier est la bonne solution. Pour des données auxquelles on accède en permanence et qui sont vitales, on optera pour des caches avec une latence très faible. Au milieu, en fonction de la structure et de la température, on a différentes solutions, parfois une intersection entre SQL, NoSQL, et Search. Nous n'avons pas encore beaucoup parlé de coûts. Regardons cet exemple concret entre S3 et DynamoDB. On veut stocker un très grand nombre de petits fichiers, peut-être un milliard, de taille typique de 2 Ko, et les écrire à 300 requêtes par seconde. En utilisant le calculateur d'AWS, on compare les coûts respectifs sur S3 et DynamoDB. Sur S3, on entre le volume de données, la taille des items, le nombre d'écritures par seconde. Sur DynamoDB, on entre le nombre de requêtes par mois. Dans ce cas, DynamoDB peut être la meilleure solution, avec un rapport de 1 à 6 ou 7 entre DynamoDB et S3. Si la taille des objets augmente à 32 Ko, S3 devient plus de deux fois moins cher que DynamoDB. Il est important de revisiter régulièrement les hypothèses initiales pour s'assurer qu'on a toujours la bonne solution. L'analyse des données se fait avec différents outils, de plus en plus souvent en intégrant des services d'IA et de machine learning. Le big data est souvent le préalable à une analyse avec du machine learning. Sur AWS, on a une chaîne complète, avec des services de Big Data et de machine learning. On peut faire du data warehousing avec Redshift, du requêtage avec Athena, du traitement de données avec Hadoop, Spark, etc. Pour le streaming, on a la Kinesis Client Library, Kinesis Analytics pour des requêtes SQL en temps réel, et Lambda pour des traitements immédiats. Le choix dépend de la latence souhaitée. Pour des volumes importants et une latence en minutes ou heures, EMR est généralement la solution. Pour des interactions humaines ou des dashboards, on opte pour Redshift et Athena. Pour du traitement en temps réel, on peut utiliser Spark Streaming sur EMR, Kinesis Analytics, une application développée avec la Kinesis Client Library, ou Lambda. Pour des comportements prédictifs, les services d'IA comme Recognition ou Poly offrent des réponses en temps réel, et les données traitées peuvent être envoyées vers des workflows de Deep Learning avec MXNet, TensorFlow, etc. Voilà, je vous laisse regarder ce tableau sur les différents choix possibles pour les technologies de traitement de stream. Idem pour les utilisateurs d'analyse, nous les verrons tout à l'heure dans la démonstration. Je parlerai de la démonstration juste à la fin, mais vous verrez les différences qui peuvent exister entre Redshift, Athena et d'autres. Il y a un point dont nous n'avons pas parlé, c'est l'ETL qui est souvent une étape importante des traitements Big Data. Il existe un certain nombre de produits sur le marché pour faire de l'ETL et qui sont probablement des partenaires d'AWS. Vous en voyez certains ici. Nous avons lancé l'année dernière un service d'ETL qui s'appelle Glue, que je vous montrerai aussi tout à l'heure, et qui est un ETL qui va vous permettre d'aller piocher des données dans différentes sources, de les transformer automatiquement, de définir des jobs de transport, et de les pousser vers une destination. Le tout en gérant un catalogue de données. L'avantage de Glue, c'est qu'il est complètement managé, donc vous ne gérez aucune infrastructure. Vous verrez, il est vraiment particulièrement simple à utiliser. Il peut vous proposer automatiquement des scripts de transformation de vos données, donc il vous simplifie bien la vie. Nous verrons tout à l'heure. Donc voilà où nous en sommes, le tableau de famille est en train de se remplir, il nous reste une dernière étape à regarder qui est l'étape de consommation. Cette étape peut être extrêmement variée. Il peut y avoir de la consommation par des applications, donc vous pouvez avoir des applications qui tournent dans EC2 ou qui tournent dans un container, ça peut être sur ECS, ça peut être sur Fargate, etc. Des applications qui vont aller piocher peut-être dans S3, peut-être dans RDS, peut-être dans Redshift, des données que vous aurez traitées, agrégées, etc. L'autre possibilité, c'est que vous ayez des utilisateurs humains qui accèdent à ces données. On peut les regrouper en deux grandes catégories. Il y aura des gens qui vont faire de la data science ou des développeurs qui vont vouloir regarder ces données, les comprendre, les préparer, les utiliser pour faire du machine learning, comme nous l'avons dit. On pourra se connecter avec Jupyter ou avec d'autres outils via le SDK AWS ou via des connecteurs standards JDBC, etc., aux différents back-ends dont nous avons parlé pour ensuite exploiter la donnée. Et puis il peut y avoir des utilisateurs plutôt métiers qui, eux, veulent via une application comme Tableau ou un service comme QuickSight, faire de l'exploration, de la visualisation de données mais plutôt pour des fins business, du reporting. Donc là, on trouvera le panel habituel, des services en bonne et due forme EC2, ECS, QuickSight, etc. Des outils open source qui pourront se connecter au back-end en utilisant des technologies standards. Puis des applications métiers que vous trouverez sur la marketplace AWS, Tableau, Looker, MicroStrategy, Click, etc., qui se connecteront là aussi avec des connecteurs standards pour aller visualiser les données. Donc un large choix. Si on résume, vous voyez que le tableau de famille est relativement large, mais en même temps, on arrive quand même à définir des grilles d'évaluation, des grilles de lecture classiques, qui doivent vous permettre, sur la base de critères finalement relativement simples, de trouver le bon chemin et la bonne combinaison. Je vous incite à regarder, à peut-être reposer les différents tableaux récapitulatifs dont nous avons rapidement parlé, et puis à les comparer aux données avec lesquelles vous êtes amené à travailler. Vous verrez que généralement, ça se dégrossit assez vite. Parfois, on se dira, bon, OK, pour l'ingestion, c'est plutôt clair. Pour le stockage, OK, c'est plutôt clair. Par contre, est-ce que je prends Redshift ? Est-ce que je prends Athena ? Peut-être qu'il faut tester rapidement les deux et se faire une religion et choisir celui de ces services qui vous plaît le plus, qui vous paraît le plus efficace. Finissons avec quelques patterns qu'on rencontre souvent chez nos clients. Un premier pattern pour l'analyse temps réel. L'analyse temps réel va commencer par une collecte de flux qu'on va envoyer vers Kinesis, sur lequel on peut, au fil de l'eau, appliquer des traitements avec Kinesis Analytics. Puis ensuite, on aura des consommateurs de ce flux Kinesis, donc une application maison qui intégrera la KCL, des fonctions Lambda qui est le choix sans doute le plus populaire, ou un cluster EMR avec Spark Streaming. Sur la base des traitements qui sont effectués, peut-être que vous avez des sorties multiples, une sortie de logs vers S3 pour de l'archivage long terme pour garder des résultats agrégés, une sortie vers un système un peu plus chaud comme ElastiCache ou DynamoDB ou RDS pour ensuite évidemment servir des données à des applications ou à des utilisateurs, et peut-être des données urgentes, une espèce de fast track pour des alertes, des notifications temps réel, du monitoring, que sais-je, vers d'autres files de messages comme Kinesis ou des notifications SNS pour alerter des systèmes en aval de votre architecture Big Data. Voilà, cette architecture est extrêmement courante. On peut aussi avoir une architecture avec deux faces, donc une face interactive qui va ressembler à ce que je viens de décrire et puis une face batch. Là, sur la base de données, peut-être de données stream et de données fichiers, fréquent d'avoir les deux, on aura donc une première consolidation de toutes ces données dans S3, puis une exploration interactive avec Redshift, Athena, etc. Pourquoi pas avec des modèles prédictifs au milieu si on a envie. Et puis un traitement batch pour de l'agrégation des travaux plus lourds, généralement avec EMR, avec Hadoop, avec Spark, etc. Et puis ensuite, remontée de tout ça vers d'autres systèmes pour de la consommation. Vous voyez que c'est vraiment ce pattern qui est important et on voit vraiment le rôle central que joue S3 dans ces architectures. Si on pousse la logique à son terme, on aura une architecture de type data lake où, quelles que soient les données qu'on collecte, que ce soit des transactions, des fichiers, des flux, on va les collecter avec le bon système de collecte, on va tout déverser dans S3. À partir de là, on pourra déclencher des traitements temps réel, Lambda par exemple peut réagir très simplement aux dépôts de nouveaux objets dans S3 et démarrer des analyses et de la publication de données vers des systèmes chauds. Et puis on peut aussi avoir des traitements batch, donc des traitements plus froids, soit interactifs, soit batch avec Athena, Redshift, EMR, etc. Donc vraiment on voit le rôle central joué par S3 pour le stockage, les différents connecteurs dont on peut se servir pour s'adapter au type et à la granularité des données. Et puis ensuite, en aval de S3, des systèmes interactifs, batch ou des systèmes temps réel qui vont agir sur les données et les publier vers l'aval de la plateforme et vers les applications. Quand on parle de data lake, on parle rapidement de catalogue. Comment classe-t-on, comment catalogue-t-on les données ? La façon dont on le voit chez nos clients, c'est d'utiliser Glue. J'ai dit tout à l'heure que Glue était un ETL, mais qu'il avait aussi un catalogue. On le verra tout à l'heure dans la démonstration. Catalogue de données qui est utilisable par Athena, par Redshift, qui sert un peu de point central. Si vous êtes plutôt un utilisateur Hadoop, vous pourrez également utiliser le Metastore Dynastore. Hive qui peut être accédé par d'autres systèmes comme Athena, etc. Mais effectivement, Glue semble être un choix un peu plus central au sein d'AWS. Bien sûr, la sécurité et la gouvernance sont des points essentiels. Quand on parle de données, on parle rapidement de sécurité, de conformité, de droit d'accès, de chiffrement, etc. Là aussi, nous avons eu l'occasion de parler très en détail de ces services. Je vous renvoie vers les webinars sécurité que nous avons faits il y a plus d'un an maintenant, qui rentraient très en détail sur IAM, KMS pour le chiffrement, etc. Mais tout ça, tous ces services transverses de sécurité, s'intègrent facilement et sont déjà même intégrés nativement avec les services dont j'ai parlé. Le résumé du résumé, le pipeline Big Data, la collecte, le stockage, le traitement, l'analyse avec potentiellement une phase de TL au milieu, la consommation et puis en transverse, des architectures de référence pour avoir un chemin temps réel, un chemin interactif, un chemin batch et peut-être même un data lake avec S3 comme point central de l'entreprise pour le stockage et la conservation de vos données, des services de catalogue de données avec Glue et puis des services de sécurité, de chiffrement, de conformité déjà présents dans AWS depuis des années. Nos conseils sont les suivants : découplez vos systèmes, séparez bien l'ingestion, du stockage, du traitement, de l'analyse. Vous voyez que chaque étape a des contraintes différentes, chaque application peut avoir des contraintes différentes. Donc vous ne trouverez pas de couteau suisse qui sait tout faire. C'est vraiment un piège dans lequel il ne faut pas tomber. Choisissez les bons outils, analysez bien les données de vos projets au travers des grilles de lecture que je vous ai montrées et vous verrez que les choix se font assez facilement. Nous vous conseillons de vous appuyer sur les services managés, qui vous déchargent de l'architecture, qui vous déchargent de l'infrastructure, qui vous déchargent d'une grosse partie du travail d'Ops et qui vous permettront de vous concentrer sur le Big Data lui-même, les traitements à effectuer et pas sur la plomberie. Pensez à garder vos données brutes, utilisez S3 comme data lake pour toutes les données brutes et à partir de ces données brutes, projetez des versions transformées vers les différents back-end dont vous avez besoin. Attention au coût, vous voyez dans certains cas S3 est le bon choix, dans d'autres c'est peut-être DynamoDB, ces deux-là ont tendance à s'opposer souvent. Donc réévaluez périodiquement vos choix et puis autant que faire se peut, intégrez, sur la base des données que vous avez transformées grâce à vos processus Big Data, utilisez-les pour faire du machine learning, utilisez-les pour faire de l'IA et rendez vos applications plus intelligentes. Quelques ressources pour rebalayer tous ces services. Le site AWS avec la page Big Data, vous trouverez évidemment des liens vers tous les services dont j'ai parlé, des références clients en grand nombre. Nous avons un ensemble de livres blancs sur ces sujets, cette URL. Et puis pour les gens qui souhaitent des informations plus techniques, plus détaillées, qui veulent rentrer encore dans les détails, nous avons un blog Big Data qui est extrêmement fourni. Vous trouverez beaucoup d'architectures, des architectures clients, beaucoup de codes, beaucoup d'exemples. Et puis bien sûr, toutes les vidéos de re:Invent 2017, où il y a eu un très grand nombre de vidéos Big Data et Analytics au sens large. Vous en trouverez la liste exhaustive à cette URL et les vidéos elles-mêmes, vous les trouverez évidemment facilement sur YouTube. Voilà, j'en ai fini pour ce panorama Big Data. On peut en parler pendant des jours et des jours. Mais voilà, j'ai utilisé mon temps, le temps qui m'était imparti. J'espère que ça vous éclaire. N'hésitez pas à me contacter sur LinkedIn, Twitter, etc. Si vous avez des questions, si vous voulez plus de détails, je serai ravi de vous les fournir. Voilà pour ce premier webinar. Merci beaucoup. Et donc, je vous donne rendez-vous dans quelques minutes pour le deuxième webinar. Nous allons consacrer à une démonstration, donc zéro slide, que de la démonstration où nous allons utiliser Glue, Athena, Redshift, QuickSight, etc., et nous allons essayer de connecter un peu tous ces services et de vous montrer comment vous pouvez facilement construire des choses relativement évoluées. Voilà, merci beaucoup, à tout de suite. Bienvenue dans ce second webinar consacré au Big Data. Comme promis, dans ce webinar, nous allons faire une démonstration de bout en bout en combinant différents services AWS. Le premier service que nous allons utiliser est Glue pour faire de l'ETL, puis je vous montrerai Athena pour faire de l'exploration et du requêtage interactif. Ensuite, nous jetterons un œil à Redshift et Redshift Spectrum pour faire du requêtage mais combiné avec du data warehousing en utilisant des données stockées dans S3. Nous visualiserons les données avec QuickSight et puis nous nous intéresserons à la partie temps réel avec Kinesis, Kinesis Firehose, Kinesis Analytics, et nous verrons comment déployer ces services pour collecter, traiter en temps réel des données, et puis pour les déposer à nouveau dans S3 et boucler la boucle. OK ? Alors, le premier service, le début de la chaîne, c'est Glue. Glue est un ETL qui va nous permettre d'aller chercher, d'aller piocher des données qui sont stockées dans différents back-ends. Ici, je vais utiliser des données qui sont dans S3. Vous voyez ici un très gros fichier puisqu'il fait presque 1 Go. Un très gros fichier CSV qui contient des données en ligne, ce sont des courses de taxi, un dataset public que vous pouvez récupérer, l'accès à ce bucket est public. On voit ici un petit extrait des données en ligne, on voit qu'on a un vendor ID, la date de prise en charge, la date et l'heure de dépôt du client, le nombre de passagers, la distance, la latitude et la longitude du pick-up et du drop-off, le type de paiement, la distance parcourue, etc. Donc un dataset assez classique. Le but du jeu est donc d'ingérer ces données, de les requêter, de les visualiser, etc. La première étape, comme je l'ai dit, c'est d'utiliser Glue pour ingérer ces données, les cataloguer, puisqu'il y a un catalogue de données dans Glue, et puis bien sûr, c'est un ETL, donc on va les transformer. Ici, je l'ai déjà fait, je vais vous montrer comment on fait cette opération. On crée ce qu'on appelle un crawler. On va préciser où se trouvent les données. Ici, elles peuvent être soit dans S3, soit dans un backend disposant d'un connecteur JDBC, ce qui est le cas de Redshift, RDS, Athena, ou une de vos propres bases disposant d'un connecteur, etc. Donc on va indiquer le chemin, je vais récupérer le chemin qui est dans mon terminal. Ici, une seule source me suffira. Il faut bien sûr un rôle IAM, qui aura le droit d'aller lire dans S3. Si vous connectiez à Redshift, par exemple, il faudrait la permission de le faire. Ici, il existe déjà. On peut choisir la fréquence d'exécution du crawler, tous les jours, toutes les heures, etc., ou on peut le faire à la demande. On va choisir une base de données dans laquelle on va créer cette table, puisqu'il y a un catalogue, donc on va créer une base qui va contenir des tables avec le schéma. On va ajouter une base et donner un trait fixe à toutes les tables qui seront ajoutées. Il y avait des petites options, on ne les a pas regardées. On peut spécifier tout un tas de choses. Là, je suis resté sur les réglages par défaut. Voilà, c'est tout. C'est magique. Finish. Et donc maintenant, mon crawler est prêt à fonctionner. On va l'exécuter tout de suite. Évidemment, on pourrait l'effacer, faire plein de choses. Vous voyez, aller piocher des données, c'est aussi simple que ça. On va revenir sur le crawler que j'avais déjà créé. On va l'exécuter. Ça doit prendre quelques minutes. On va le laisser tourner tranquillement. Ok, donc là, ce qui va se passer, c'est qu'il va aller chercher le fichier CSV, détecter son schéma, on va le voir ici. Une fois que le job a tourné, on voit qu'on a créé une table automatiquement. On a détecté automatiquement qu'il s'agissait d'un CSV, détecté automatiquement les colonnes. Ce n'est pas très dur pour un fichier CSV. On a le nom des champs, puisqu'on avait une première ligne qui contenait les entêtes, les noms des colonnes, etc. Donc ça se fait facilement, il n'y a vraiment pas de difficulté. On construit comme ça le catalogue. Ici, on voit toutes les tables qui existent dans mon catalogue parce que j'ai d'autres tables, Athena, etc. Mais on voit ici qu'on construit facilement son catalogue de données et on importe facilement ces tables. Mon crawler doit être en train de tourner gentiment. Voilà, on va le laisser vivre sa petite vie. Une fois qu'on a fait ça, une fois qu'on est allé piocher des données et qu'on a créé le catalogue, on va pouvoir créer un job d'ETL à proprement parler. On va le faire rapidement, vous voyez un peu les étapes. Il faut un rôle, il va falloir l'autorisation de lire et écrire dans S3, etc. Un des points forts de Glue, c'est qu'il est capable de générer automatiquement un script d'ETL, en Python ou en Scala. En ce qui me concerne, on va rester en Python. On va choisir cette option, puis on verra le script qui est généré. Bien sûr, on peut le modifier, on peut s'en servir pour customiser ensuite le job d'ETL. On peut aussi fournir son propre script, si vous avez votre propre script d'ETL. Si vous avez des traitements particuliers à faire, vous pouvez créer un job avec ce script directement. On reste sur un script autogénéré, on reste en Python. On a des propriétés ici, on peut importer des librairies, gérer le niveau de concurrence, etc. On va rester simple. On va choisir une data source, donc ici on va piocher dans le catalogue qu'on a constitué. On prend ma source dans S3. On pourrait définir une cible. On va prendre un bucket, etc. On va prendre ça. Et donc là, Glue, en fonction du catalogue de données qui a été créé, va me proposer automatiquement de faire un mapping entre mes champs, soit de changer le type des colonnes. Par défaut, tout ça est identique. Mais on pourrait changer le type des champs, mapper une colonne source vers une colonne destination, etc. On va supposer qu'on ne fait aucun changement. Et voilà. On va pouvoir définir un job d'ETL assez simplement. Je ne vais pas le faire pour ne pas polluer ma console. Ici, j'ai défini un job avec un script autogénéré. Il a déjà tourné, on voit la source et le script. C'est le script d'ETL qui a été généré automatiquement par Glue. J'y ai apporté un petit modif parce que dans le catalogue, dans la table importée par le crawler, ces deux champs qui sont des heures et des dates ont été détectés automatiquement comme des strings. Donc ok, pourquoi pas, en soi c'est pas gênant, mais moi je voudrais avoir ces champs sous forme de timestamp. Donc ici, je vais renommer le champ qui a un nom un peu compliqué. Je vais le renommer en pickupdate et en type timestamp. Et puis je vais faire de même pour la drop-off date time, je vais la renommer en drop-off date et en timestamp. Donc vous voyez, on a un script qui est autogénéré, qu'on peut modifier et compléter. Plutôt sympa. Voilà pour mon job. On va peut-être pas l'exécuter, ça prend quelques minutes, on a des logs dans CloudWatch Logs, on a les logs d'exécution, ça permet de débuguer le script si jamais il y a un problème. Une fois de plus, vous pouvez laisser Glue générer un script et l'ETL se fait de manière simple. Quand vous définissez le job, vous pouvez aussi modifier le format de sortie des données, ce que j'ai également fait dans ce job. J'ai converti ce CSV, qui est un format qui pourrait être requêté directement par Athena, mais qui est un format qui n'est pas très efficace, au format parquet. Le format parquet est un format en colonne qui est un format Apache, supporté par Hive, reconnu par Athena et Redshift, qui stocke les données en colonnes et les compresse. Cela va me permettre, lorsque j'ai des datasets très larges avec un très grand nombre de colonnes, de minimiser le nombre d'IO que je vais faire pendant que je requête, puisque je vais pouvoir aller lire des blocs disques qui ne contiennent plus des lignes mais des colonnes. Je vais pouvoir sélectionner automatiquement des blocs disques qui contiennent les bonnes colonnes dont j'ai besoin, et ces blocs-là sont compressés. Donc ça va me permettre de réduire très massivement le nombre d'IO que je fais pendant que je requête. Et forcément, ça va améliorer mes performances. On verra avec Athena que ça a d'autres avantages. Donc dans mon job d'ETL, j'ai fait deux choses. J'ai converti mes deux dates de string vers des vrais formats timestamp et j'ai converti le format CSV vers parquet, que j'ai réécrit dans un autre préfixe dans mon bucket. Mon ETL a fait ça automatiquement. L'avantage de Glue, c'est qu'on ne gère pas d'infrastructure, on se contente de définir des crawlers, d'importer des données, de créer son catalogue et puis ensuite d'appliquer des jobs et de réécrire les données, probablement dans S3, pour qu'une autre application vienne s'en servir. Et puis vous avez même des scripts ETL prédéfinis que vous pouvez customiser, et si vous voulez amener votre propre script, c'est tout à fait possible. Donc un outil vraiment, c'est un outil qui manquait clairement dans la chaîne Data AWS, et on a comblé ce trou. Maintenant que mes données sont disponibles dans S3 au format parquet, je vais pouvoir les explorer. Là, je suis dans la console de Redshift. On va refaire la démo complètement. On va supprimer cette table. Très bien. Je vois ici, dans Athena, le Data Catalog de Glue. Si vous utilisez Athena depuis le début, vous avez un petit upgrade à faire qui consiste juste à aller cliquer dans une case pour lui dire d'utiliser le catalogue de Glue. Par défaut, initialement, Athena a utilisé son propre catalogue de données, mais ici, c'est bien plus simple. Vous devez voir, si vous utilisez Athena depuis le début, vous allez cliquer sur ce truc là et ça va vous dire ok, en gros, je veux basculer sur le data catalogue de Glue et automatiquement tout ce qui était dans le data catalogue d'Athena va être également poussé là-bas, donc vous ne perdez rien pour trouver toutes les métadonnées liées à vos tables, etc. Donc ici, je vois mon catalogue, je vois ma table. Je vois la table qui a été importée par mon crawler. Et maintenant, je vais devoir créer dans Athena une table qui sera une table externe. Une table externe, ça veut dire une table qui correspond à des données stockées dans S3. Là, je n'ai Athena, un service complètement serverless. Je ne provisionne aucune infrastructure. Je me contente de définir un schéma qui référence les données qui sont dans S3 avec le bon schéma. Donc je suis obligé d'utiliser ici les nouveaux types timestamp que j'ai bien définis tout à l'heure dans mon job d'ETL. Donc on va exécuter cette requête, on précise bien que les fichiers sont en format parquet, le préfixe précis dans S3. Voilà, donc là j'ai créé ma table. Je vois que mon catalogue se met à jour, donc j'ai ma table initiale, stockée au format CSV dans S3, et j'ai ma nouvelle table externe qui pointe, entre guillemets, sur mes fichiers parquets dans S3. Et voilà, maintenant je peux requêter. On pourrait compter le nombre de lignes qui sont dans cette table. Donc, un peu moins de 11 millions. On pourrait en afficher quelques lignes, on voit la tête que ça a. On voit 5 lignes ici avec la vingtaine de champs à peu près de mon jeu de données. On pourrait faire un truc plus rigolo. On va sommer toutes les courses de taxi et les ordonner par type, les grouper par rate code, par type de tarif. On va les sommer. Donc vous voyez, on a déjà parlé d'Athena, je vous l'avais déjà montré, mais si c'est la première fois que vous le découvrez, vous voyez qu'avec Athena, on a instantanément, sur la base de données qui sont dans S3, la capacité, modulo la création de cette table externe pour venir plaquer un schéma sur les données qui sont dans S3, opération qui prend une seconde, et bien on a ensuite la possibilité de venir requêter avec du SQL complètement standard ces données dans S3 sans avoir créé d'infrastructure. Donc là, je n'ai une fois de plus rien provisionné dans Athena. J'ai ouvert la console, j'ai créé ma table et je requête. Premier avantage. Deuxième avantage, je lis les données au format où elles sont. Je pourrais requêter aussi ma table CSV. Ça serait évidemment plus long. D'où ma conversion parquet par Glue. Je n'ai rien géré. Donc je n'ai pas de délai, je n'ai pas besoin de venir charger des données, je requête instantanément. Et puis quatrième point, la facturation d'Athena est uniquement liée au volume de données scannées. Donc on voit que cette requête, cette dernière requête que je viens d'exécuter, a scanné 16,3 mégaoctets de données, ce qui est très faible, lié au fait que j'utilise un format en colonne. Donc ici, très concrètement, je ne suis allé lire que les blocs disques qui contiennent la colonne RAID CODE ID et les blocs qui contiennent la colonne TRIP DISTANCE. J'ai ignoré les blocs qui contiennent les autres colonnes. Et en plus, j'ai de la compression. Donc je n'ai lu que 16 mégas. Et donc là, le coût de cette requête est uniquement lié à ça. Il est uniquement lié au volume de données que j'ai lues. Ce qui veut dire que lorsque je ne requête pas, je ne paye pas. C'est très simple, le coût d'Athena est uniquement le coût de requête. Donc si on regarde l'historique ici, des requêtes qu'on a passées, à chaque fois on voit la requête, on voit le temps d'exécution, le volume de données scannées, on pourrait en télécharger également les résultats. Voilà, mais une fois de plus, la facturation d'Athena est uniquement ça et rien d'autre. Donc lorsque vous ne requêtez pas, vous ne payez rien puisque vous n'avez pas provisionné d'infrastructures et c'est tout. Vraiment, Athena est un service, moi j'aime beaucoup ce service, il est facile à mettre en œuvre, il est facile à déployer, il n'y a pas d'ingestion, il n'y a pas de temps perdu à créer des clusters et surtout quand on ne s'en sert pas, il ne coûte absolument rien. Alors voilà pour Athena. Donc exploration, utilisation interactive. Maintenant, une fois que vous avez fait ça, il est quand même probable que vous ayez envie d'avoir une utilisation un peu plus poussée sur vos données. Il est possible que, certes, vous ayez des données, disons, froides. Mais il est également probable que vous ayez des données chaudes, des données d'entreprise qui servent tous les jours à faire des dashboards, à faire fonctionner vos applications, etc. Et il est probable qu'elles soient dans Redshift. Donc ici, l'étape suivante, c'est de se dire, OK, j'ai des données qui servent, qui sont dans S3, c'est très bien, je les ai chargées, etc. Cela est particulièrement utile pour exécuter des requêtes impliquant des données chaudes dans Redshift et des données froides dans S3. Les requêtes sont envoyées au cluster Redshift, qui les redirige à la flotte Spectrum pour le traitement. Si vous avez déjà un cluster Redshift, il est judicieux de réexaminer les données stockées et de déplacer certaines vers S3 pour réduire la taille du cluster et faire des économies. Cela permet de séparer la puissance de traitement et la capacité de stockage, offrant un cluster plus petit mais potentiellement plus puissant pour le même coût. Les données tièdes ou froides peuvent être migrées vers S3 tout en continuant à faire des jointures et des traitements. Cette optimisation peut entraîner des économies substantielles et améliorer les performances sur les données les plus chaudes. Pour visualiser les données, QuickSight est un outil managé qui se connecte facilement à Redshift pour créer des dashboards interactifs. On peut créer des histogrammes, des courbes, et zoomer sur des données spécifiques. QuickSight est économique et offre une granularité flexible, permettant de visualiser les données par jour, par heure, etc. Il est possible de faire des drill-downs pour analyser des événements précis, comme un pic de trafic ou une baisse de revenus. Pour le streaming, Kinesis Firehose est un service managé qui permet de recevoir des événements et de les déverser dans S3, Redshift, ou Elasticsearch. Ici, j'ai configuré un générateur de données pour envoyer des événements JSON dans un stream Kinesis, qui sont ensuite déversés dans S3 toutes les 5 minutes ou tous les 5 mégas. Kinesis Analytics permet de requêter ces événements en temps réel avec des requêtes SQL, comme détecter les taxis roulant à plus de 50 miles/heure. Les transformations peuvent être appliquées via des fonctions Lambda, permettant un traitement serverless des données en temps réel. En résumé, nous avons couvert des services comme Glue pour l'ETL, Athena pour les requêtes serverless, Redshift pour le data warehousing avec Spectrum, QuickSight pour la visualisation, et Kinesis pour le streaming. Ces services sont managés, permettant de se concentrer sur l'analyse des données sans se soucier de la gestion de l'infrastructure. J'espère que cela vous donne envie de les essayer. Merci de m'avoir écouté, et à bientôt pour une nouvelle série de webinars sur les FPGA et les instances F1. N'hésitez pas à consulter notre chaîne YouTube, Amazon Web Services France, et à me contacter sur Twitter si vous avez des questions. Merci, bonne fin de journée.