Entrez dans le monde serverless en creant un scraper automatique de Twitter sur AWS en cinq etapes simples

Cet article a ete ecrit avant le changement de nom de Twitter et la suppression ulterieure de son API. Meme si vous ne pourrez pas reproduire l’exemple tel quel, l’idee s’applique exactement de la meme maniere pour n’importe quelle autre API. Quelques exemples interessants pour vous entrainer : celle de Binance ou celle d’Openweather.

Serverless ou “le nom le plus mal choisi de l’histoire”

Si vous debutez votre carriere dans la data, ou si vous commencez tout juste a decouvrir le monde du cloud, vous avez surement croise plus d’une fois le terme serverless. Meme si le nom pourrait laisser penser qu’il s’agit de quelque chose sans serveurs, l’idee est en realite completement differente.

Serverless signifie que la personne qui developpe n’a pas acces a l’infrastructure sous-jacente, generalement fournie par un fournisseur cloud (AWS, GCP, Azure, etc.).

Il faut mentionner que le monde serverless gagne du terrain ces dernieres annees car il presente des avantages significatifs tant pour les developpeurs que pour le metier :

• Meme si c’est une arme a double tranchant, l’avantage pour les data scientists et les developpeurs en general est qu’on prend peu de risques d’installer quelque chose qui pourrait casser un environnement.

• Cote business, dans la plupart des cas, une bonne architecture serverless pilotee par evenements genere une meilleure efficacite en termes de couts et de controle sur ce qui se fait dans l’organisation.

Le monde serverless peut etre intimidant, alors le mieux c’est de le voir en action. Ceci est le premier de trois articles ou on va progressivement avancer vers une architecture de plus en plus automatisee, en faisant grandir un developpement ou on va interroger l’API de Twitter et stocker les resultats dans S3 pour les exploiter ensuite.

Au boulot !

Ce dont on va avoir besoin a cette etape :

• Une API Key developpeur Twitter (la v2 de l’API s’obtient instantanement et suffit pour notre cas).

• Un acces a AWS avec les roles qui nous permettent d’interagir entre Lambda, S3 et EventBridge.

• Un bucket dans S3.

En optionnel, l’acces a un notebook AWS SageMaker (et les roles requis, en particulier pour se connecter a S3).

Etape 1 : Monter et tester le scraper

Voyons le code du scraper :

• Avec tweepy, on peut interagir avec les services de Twitter. La documentation est tres complete et offre des methodes et classes tant pour la v1 que la v2 de l’API.

• On s’authentifie via l’OAuthHandler, ou on va passer le bearer token que Twitter nous donne a la creation de cette application. Il est tres important de preserver la securite de ces cles d’acces, qui ne sont en aucun cas publiques. Normalement, on commence par le mettre “comme ca”, mais plus tard on verra comment stocker cette cle dans une variable d’environnement de la Lambda qui va executer l’appel a Twitter.

• On selectionne les champs du tweet qui nous interessent.

• La query peut etre n’importe quoi… comme des news sur Magic. Oui, c’est la query avec laquelle j’ai teste ; et non, je ne regrette rien.

• D’abord on instancie le client avec notre cle d’acces et on cherche les tweets avec quelques parametres de notre choix.

• On convertit la reponse en dataframe Pandas, et voila !

Etape 2 : Uploader les donnees dans un bucket AWS

L’etape suivante est de les uploader dans un bucket S3 (stockage simple d’objets) pour les exploiter a volonte.

Voyons comment :

• Maintenant la query definitive est en place : on va chercher ce qui se dit sur Ethereum, mais ca peut etre n’importe quoi !

• On instancie une variable avec le nom de notre bucket. Cette facon indirecte de construire les destinations (ne pas faire l’appel direct au nom dans la creation de l’objet s3.Bucket mais la variable BUCKET dans la cellule 8) sera tres utile par la suite (et c’est une bonne pratique).

• Justement dans la cellule 8, on voit qu’avec boto3 (la bibliotheque Python pour interagir avec les services AWS) on instancie l’acces a S3, et avec ca, l’acces au bucket avec lequel on veut travailler.

• Attention : pour uploader vers S3, il faut d’abord sauvegarder les donnees sur disque (les dumper), parce que ce dataframe qu’on a recupere de Twitter est stocke uniquement en RAM (on sauvegarde dans test.csv).

• Pour l’uploader, via l’objet bucket on indique le chemin et nom du fichier qu’on veut uploader (“test.csv”) et la meme chose pour le fichier tel qu’on veut qu’il apparaisse dans le cloud, dont le chemin et le nom peuvent parfaitement etre differents (et le seront surement, comme dans l’exemple, ou il s’appelle “test2.csv”) :

Etape 3 : Construire les lambda layers

On accelere un peu et on passe a fond dans le cloud !

Les lambdas sont des fonctions en tant que service : on met le code et AWS monte une infrastructure derriere pour l’executer. Comme l’idee est que tout soit le plus leger possible, les lambdas embarquent de base uniquement les bibliotheques essentielles.

C’est pourquoi, pour utiliser une bibliotheque un peu moins basique (ca peut surprendre, mais ca inclut Pandas !), il faut ajouter des couches (layers) qui etendent les fonctionnalites de base.

AWS en propose quelques-unes par defaut pour les cas courants (on va utiliser celle qui ajoute Pandas, justement), mais pour les cas moins classiques (comme Tweepy), il faut les construire a la main, et pour ca il faut faire une installation locale de la bibliotheque.

Avant de creer la lambda elle-meme, construisons cette layer :

• On fait un classique pip install, mais en ajoutant l’argument -t, qui indique le target ou on veut l’installer. Dans ce cas, on indique un dossier appele python que j’ai cree au prealable : ce nom est obligatoire pour que la Lambda puisse fonctionner.

• On voit qu’une fois termine, dans le dossier python restent tous les elements de l’installation de la bibliotheque.

Avec ca fait, l’etape suivante est de le compresser et de l’uploader comme layer de lambda, ce qu’on peut faire en uploadant le fichier ou en indiquant un chemin vers un S3 contenant le .zip. Heureusement, l’interface vous guide et ce n’est pas une etape complexe : la seule obligation est de donner un nom a la layer (dans notre cas, tweepy).

Etape 4 : Construire la lambda

Tout est pret, on peut construire la lambda elle-meme.

• On a besoin d’un nom (au choix), d’un runtime (Python 3.8) et d’une architecture (x86_64).

• Cote permissions, il en faut un qui ait acces en ecriture a S3. Si vous ne savez pas comment faire, voici un post ou on explique la marche a suivre.

Avec ca, un editeur de texte s’ouvre ou on peut mettre notre code. La nouvelle version a peu de changements mais significatifs :

• Il y a une fonction appelee “lambda_handler” au milieu. Sans entrer dans les details, c’est la fonction qui sera executee automatiquement par AWS, donc tout le code qu’on veut executer doit aller a l’interieur.

• De haut en bas : on importe les bibliotheques et on instancie quelques variables avec des noms. A travers la concatenation de ces variables, on va construire tant les chemins des fichiers que les noms eux-memes de maniere programmatique :

1. LOCAL_LAMBDA_FOLDER : Pour pouvoir sauvegarder sur disque dans le contexte d’une lambda, il faut ecrire ce qu’on veut dans le dossier tmp/.

2. FOLDER_STRUCTURE : Via boto3, on peut uploader vers n’importe quel emplacement, tant que le chemin est correct. Avec cette methode, on construit une structure propre pour stocker les donnees.

• D’abord on obtient un timestamp qu’on va utiliser pour construire le nom du fichier, en lui ajoutant l’extension du fichier sur la ligne juste en dessous.

• Ce LOCAL_FILENAME (la date + l’extension) sera utilise pour construire le chemin de destination dans S3 (en respectant la structure du datalake) et le chemin ou il sera stocke apres le dump.

• Ici on utilise les variables d’environnement de Lambda pour cacher l’API Key. Via OS, on accede a une variable d’environnement appelee BEARER_TOKEN qu’on definit dans l’interface, dans la section correspondante :

• Enfin, on ajoute quelques prints dans la console pour superviser les logs.

Avec le code pret et prepare, on ajoute les couches. En haut, sous le nom de la fonction, se trouve la section Layers. Le processus est simple : cliquer et ajouter les couches souhaitees :

• D’abord, dans l’option AWS Layers, choisir AWSDataWrangler-Python38 (celle qui correspond a la version de la Lambda).

• Ensuite, dans Custom Layers, choisir l’option qu’on a creee.

Il ne reste plus qu’a la tester ! Pour ca, on clique sur Test, on donne n’importe quel nom a l’evenement et on lance le test. Si tout s’est bien passe, dans votre dossier S3 vous devriez voir un fichier .csv fraichement cree.

Etape 5 : Programmer l’execution

La derniere etape est de configurer l’evenement qui declenche l’execution de la lambda de facon periodique. Pour ca, on clique sur Add Trigger et on construit la regle :

Detail sympathique : en plus des classiques expressions cron (UNIX), il accepte certaines expressions en anglais (comme dans l’exemple). On clique sur Add, et si tout s’est bien passe, ca s’executera toutes les cinq minutes.

Et ensuite ?

• La partie sur l’evenement et ses tests : jusque-la ca semble esoterique, mais c’est un element crucial dans l’orchestration via EventBridge.

• Pour l’instant, tout est sauvegarde dans le meme dossier, et ce n’est clairement pas la bonne facon de stocker des donnees dans un datalake. Pour ca, il faut partitionner les donnees, en stockant chaque element dans des dossiers bien plus segmentes en fonction du moment ou l’information a ete extraite de Twitter.

Mais ca, ce sera dans la partie 2 !