Questi quattro passaggi descrivono un caso d’uso relativamente semplice ma molto comune. Ora proviamo a redigere un elenco di passaggi che dobbiamo eseguire in AWS Glue per completare il flusso di lavoro descritto finora:<\/p>\n\n\n\n
- Scansionare il database originale tramite una connessione JDBC.<\/li>
- Utilizzare un Glue Job per spostare i dati dal database a S3. Alcune tabelle possono utilizzare i segnalibri ma altre no.<\/li>
- Scansionare il bucket S3 di destinazione.<\/li>
- Eseguire un job di Glue Spark dedicato per operare una join sul data lake di S3. Scrivere i risultati su un’altra partizione o bucket S3.<\/li>
- Eseguire la scansione della partizione di destinazione per rendere facilmente interrogabili i risultati della join mediante AWS Athena.<\/li>
- Lanciare il job di ML (SageMaker o workflows di Glue ML).<\/li>
- Scansionare il set di dati risultante.<\/li>
- Eseguire un processo ETL finale di Glue per caricare il nuovo set di dati nel database originale.<\/li><\/ol>\n\n\n\n
Tutti questi passaggi devono essere eseguiti nell’ordine indicato e, in caso di problemi, sarebbe bello essere avvisati e avere un modo semplice per capire cos’\u00e8 andato storto.\n<\/p>\n\n\n\n
Senza utilizzare AWS StepFunctions, la gestione manuale di questi passaggi sarebbe estremamente difficoltosa e probabilmente avremmo bisogno di uno strumento di orchestrazione esterno o di creare uno script di orchestrazione personalizzato da eseguire su un\u2019istanza EC2 o su un container Fargate.<\/p>\n\n\n\n
Ma perch\u00e9 preoccuparsi? AWS StepFunctions fa tutto questo per noi, ed essendo in grado di interagire direttamente con molti servizi AWS, molte integrazioni sono un gioco da ragazzi: ad esempio, con poche righe di linguaggio Stepfunctions, possiamo catturare tutti gli errori in una pipe e inoltrarli a un topic SNS per ricevere un’e-mail in caso di errore (o una notifica slack, SMS o qualsiasi altra alternativa si preferisca)<\/p>\n\n\n\n
La gestione di flussi complessi diventa cos\u00ec sicura e relativamente facile. Ecco un esempio:<\/p>\n\n\n\n
![\"AWS](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image2-625x1024.png\")
StepFunctions flow<\/em><\/figcaption><\/figure><\/div>\n\n\n\n Se uno di questi passaggi dovesse fallire, riceveremo una notifica tramite posta elettronica dal topic SNS, avremmo quindi, un feedback visivo del passaggio non riuscito e anche i log corrispondenti.<\/p>\n\n\n\n
![\"Step](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image3.png\")
Step di errore e relativi log<\/figcaption><\/figure><\/div>\n\n\n\n StepFunctions sembra quindi essere un jolly perfetto, con molte buone caratteristiche e nessun inconveniente significativo, tuttavia, come tutti sappiamo, questo non \u00e8 quasi mai vero nel mondo IT, quindi qual \u00e8 il trucco?\n<\/p>\n\n\n\n
Il vero problema \u00e8 la gestione del codice: il linguaggio di StepFunctions<\/a> \u00e8 basato su un modello JSON dichiarativo, risultando quindi non banale da scrivere e mantenere, anche utilizzando strumenti dedicati come plug-in specifici per Visual Studio<\/a>.<\/span><\/p>\n\n\n\n
Inoltre, sarebbe molto utile poter mantenere sia il codice StepFunctions che i Glue Jobs e l’eventuale codice Lambda in un unico progetto integrato.<\/p>\n\n\n\n
Cloudformation con Troposphere o AWS CDK<\/h2>\n\n\n\n
Lo strumento pi\u00f9 ovvio che possiamo utilizzare per mantenere le StepFunctions, i Glue Jobs e il resto della nostra infrastruttura ETL, in modo coeso, \u00e8 Cloudformation, da integrare come strumento di distribuzione per tutto il progetto. Tuttavia, il codice Cloudformation \u00e8 un linguaggio YML \/ JSON dichiarativo non troppo diverso dal codice delli funzioni di StepFunctions, e includere tale codice in questi template, di solito \u00e8 piuttosto doloroso poich\u00e9 implica l’inclusione di stringhe JSON complesse nel nostro file YML di Cloud Formation.<\/p>\n\n\n\n
Una soluzione molto pi\u00f9 efficace consiste nel creare un template di Cloudformation, utilizzando un linguaggio di programmazione di alto livello come AWS CDK<\/a> che supporta molti linguaggi (TypeScript, Python, e Java).<\/span><\/p>\n\n\n\n
Optando per Python, che risulter\u00e0 spesso una buona scelta poich\u00e9 i lavori ETL saranno probabilmente scritti comunque in Python, si avr\u00e0 la possibilit\u00e0 di utilizzare Troposphere invece di AWS CDK come framework Cloudformation, che \u00e8 molto pi\u00f9 versatile in diverse situazioni.<\/p>\n\n\n\n
Inoltre le StepFunctions possono essere generate a partire dal python Step Functions Framework<\/a> come mostreremo nell’esempio seguente (Troposphere + Python step function SDK).<\/span><\/p>\n\n\n\n
In questo esempio molto semplice vogliamo dimostrare come creare un semplice workflow per scaricare un dataset sul Covid da un bucket AWS S3 OpenData pubblico, salvarne un piccolo sottoinsieme in un bucket S3 diverso e sottoporlo a scansione per prepararlo alle query mediante AWS Athena. Questo esempio di workflow base pu\u00f2 essere esteso a piacimento! Ecco uno schizzo di base dell’infrastruttura:<\/p>\n\n\n\n
![\"Infrastruttura](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image5-1024x576.png\")
Infrastruttura per il nostro esempio di flow<\/span><\/i><\/figcaption><\/figure><\/div>\n\n\n\n Prima di tutto procediamo installando la CLI di AWS<\/a> <\/span>e le librerie richieste da python: <\/span><\/p>\n\n\n\n
pip install troposphere stepfunctions.<\/pre>\n\n\n\n
Una volta completata l’installazione, scarichiamo il codice di esempio dal nostro repository<\/a><\/span> e ci ritroveremo con un file <\/span>troposphere_main.py<\/span> che contiene la <\/span>rappresentazione troposphere<\/b> dell’intera infrastruttura (vedi sketch) e altre cartelle contenenti il \u200b\u200bcodice python delle varie funzioni Lambda (start_crawler, check_crawler status), infine un file README che spiega come eseguire il progetto. Dopodich\u00e9 dovremo creare un bucket S3 come supporto per la distribuzione di Cloudformation con il nome che preferiamo.<\/span><\/p>\n\n\n\n
Seguendo le istruzioni presenti nel README, possiamo semplicemente eseguire il file principale, lanciando in una console python troposphere_main.py. Eseguendo questo script, compileremo il codice troposphere in un formato JSON compatibile con Cloudformation. Fatto ci\u00f2, siamo pronti per lanciare il nuovo template di AWS Cloudformation:<\/p>\n\n\n\n
aws cloudformation package –template-file troposphere_main.json –s3-bucket <YOUR CLOUDFORMATION S3 BUCKET> –s3-prefix ‘<THE PATH YOU PREFER>’ –output-template-file troposphere_main.yml<\/span><\/p>\n\n\n\n
Questo comando prende come input il file JSON creato da Troposphere, carica su S3 il codice delle funzioni Glue e lambda, a cui si fa riferimento, come percorsi locali ed infine restituisce un altro modello di Cloudformation (questa volta in YML), in cui i riferimenti ai percorsi locali sono stati modificati nei corrispondenti riferimenti su S3 (Qui ulteriori informazioni<\/a>).<\/span><\/p>\n\n\n\n
Finalmente siamo pronti per distribuire il modello Cloudformation utilizzando il comando:<\/p>\n\n\n\n
aws cloudformation deploy –template-file .\/troposphere_main.yml –stack-name testStepfunctionsStack –capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND<\/span><\/p>\n\n\n\n
In questo modo creeremo il \u201c<\/span>testStepfunctionsStack<\/b>\u201d che contiene l’infrastruttura descritta prima. Ora possiamo accedere alla console di AWS StepFunctions ed eseguire la nuova funzione (test-stepfunctions-glue), il workflow verr\u00e0 eseguito e noi vedremo importati i dati Covid.<\/span><\/p>\n\n\n\n
![\"AWS](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image4.png\")