Di solito, questo processo prevede diversi passaggi, il coordinamento della loro esecuzione, l’accesso a diversi database con diverse tecnologie, la preparazione di molti script, la conoscenza di diversi linguaggi per interrogare i dati rilevanti e cos\u00ec via.<\/p>\n\n\n\n
Prendersi cura di tutti questi passaggi \u00e8 un compito ardito e richiede molta esperienza e, naturalmente, tempo, minando l’efficienza dell’intero progetto che si deve gestire.<\/p>\n\n\n\n
AWS, che sta progredendo molto rapidamente negli ultimi due anni nello sviluppo di strumenti e servizi per aiutare nelle attivit\u00e0 di machine learning<\/strong>, questa volta ci porta un altro importante servizio in soccorso: AWS Elastic Views<\/strong>. <\/p>\n\n\n\n AWS Elastic Views consente a un utente di richiedere dati da diverse fonti in modo completamente indipendente dalla loro natura, di eseguire query per i dati in un linguaggio compatibile con SQL e di inviare tutti i dati interrogati a una destinazione, tipicamente S3 o un’altra destinazione dati, ed infine a produrre un data lake con cui lavorare.<\/strong><\/p>\n\n\n Alcuni dei principali vantaggi sono: <\/p>\n\n\n\n Lo scopo di questo articolo \u00e8 guidare il lettore nell’esplorazione di alcuni dei fattori chiave che rendono questo servizio qualcosa di cui essere definitivamente consapevoli nei propri progetti di Machine Learning.<\/p>\n\n\n\n Esploreremo in profondit\u00e0 ci\u00f2 che \u00e8 in grado di fare AWS Elastic Views, considerando per\u00f2 che \u00e8 ancora in fase beta, quindi si dovr\u00e0 richiedere l’accesso ad AWS per l’anteprima.<\/p>\n\n\n\n Cominciamo! <\/p>\n\n\n\n Cominciamo il nostro viaggio capendo che cos\u2019\u00e8 AWS Glue Elastic Views, e come funziona<\/strong>. Per prima cosa, diamo uno sguardo allo schema fornito da AWS:<\/p>\n\n\n Come mostrato nell’immagine, il punto focale di questo servizio \u00e8 rappresentato dalla Materialized View,<\/strong> che \u00e8 un sistema per astrarre il set di dati da qualsiasi tipo di sorgente: ad esempio Amazon Aurora, RDS o DynamoDB. Ci\u00f2 consente di mantenere le informazioni sincronizzate senza l’uso effettivo di un Glue Crawler, come ci saremmo aspetti dai nostri altri articoli sui workload ETL (qui<\/a> e qui<\/a> alcuni esempi).<\/p>\n\n\n\n Ma diamo un’occhiata in dettaglio alle caratteristiche principali e come possono essere utili.<\/p>\n\n\n\n AWS Glue Elastic Views consente a uno sviluppatore di creare viste materializzate su diverse origini di dati, utilizzando query SQL per aggregare i dati. AWS Glue Elastic Views attualmente supporta Amazon DynamoDB, Redshift, S3 e Elasticsearch Service. Inoltre, AWS ha in programma di aggiungere ancora pi\u00f9 origini di dati in futuro.<\/p>\n\n\n\n AWS Glue Elastic Views gestisce per noi il lavoro pi\u00f9 pesante di copia e aggregazione dei dati da tutte le origini dati fino agli archivi di destinazione, senza dover scrivere codice personalizzato o utilizzare strumenti ETL e linguaggi di programmazione complessi o sconosciuti, con un effetto benefico sia sul tempo che sull’efficienza del progetto. AWS Glue Elastic Views riduce il tempo necessario per combinare e replicare i dati negli archivi dati da mesi a minuti, secondo AWS.<\/p>\n\n\n\n Mantenere i dati sincronizzati di solito richiede la creazione e la manutenzione di crawler, AWS Glue Elastic Views, invece, monitora continuamente le modifiche ai dati negli archivi dati iniziali e, quando si verifica una modifica, Elastic Views aggiorna automaticamente le destinazioni. Ci\u00f2 garantisce che le applicazioni che accedono ai dati utilizzando Elastic Views dispongano sempre dei dati pi\u00f9 aggiornati.<\/p>\n\n\n\n AWS Glue Elastic Views avvisa in modo proattivo gli sviluppatori quando viene apportata una modifica al modello di dati in uno degli archivi dati di origine, in modo che possano aggiornare le loro visualizzazioni per adattarsi a questa modifica velocemente.<\/p>\n\n\n\n AWS Glue Elastic Views \u00e8 completamente serverless e aumenta o diminuisce automaticamente la propria capacit\u00e0 per adattarsi automaticamente ai carichi di lavoro. Non c’\u00e8 hardware o software da gestire e, come sempre, un utente paga solo per le risorse che utilizza.<\/p>\n\n\n\n Essendo un servizio ancora in beta \u00e8 necessario registrarsi per la preview gratuita: per farlo, \u00e8 sufficiente andare a questo indirizzo<\/a> e registrarsi, compilando l\u2019apposito form.<\/p>\n\n\n Verranno richiesti i dettagli personali e aziendali, nonch\u00e9 un’introduzione di base al problema che si desidera risolvere utilizzando AWS Glue Elastic Views. \u00c8 bene Assicurarsi di fornire motivazioni ragionevoli, poich\u00e9 casi d’uso interessanti aumentano le possibilit\u00e0 di essere selezionati per l’anteprima. <\/p>\n\n\n\n Di solito, AWS risponde entro una settimana e se idoneo per l’anteprima, il seguente messaggio verr\u00e0 inviato alla propria email.<\/p>\n\n\n Dopo essersi registrati, per accedere a Glue Elastic View \u00e8 necessario cliccare sul link fornito nella mail.<\/p>\n\n\n\n Ora siamo pronti per iniziare il nostro primo workload ETL con Elastic View, invece di utilizzare script Spark standard o Glue Crawler.<\/p>\n\n\n\n Il modo migliore per capire le possibilit\u00e0 di questo servizio \u00e8 metterci alla prova con esso. Quindi abbiamo deciso di creare un semplice caso d’uso per presentare come potrebbe essere utilizzato per semplificare i propri workload ETL.<\/p>\n\n\n L’idea di base \u00e8 popolare una tabella DynamoDB con alcuni dati di test ottenuti da fonti di dati gratuite. Vogliamo estrarre e manipolare i dati da questa tabella per dimostrare come Glue Elastic Views pu\u00f2 aggiungere efficacemente funzionalit\u00e0 ETL a DynamoDB, che \u00e8 storicamente un po’ debole su questo aspetto. <\/p>\n\n\n\n Quindi vogliamo inviare questi dati a S3 e verificare che sia possibile aggiornarli in tempo reale per riflettere i cambiamenti, dimostrando come Glue Elastic Views pu\u00f2 accelerare efficacemente il processo di indagine di una pipeline di Machine Learning.<\/p>\n\n\n\n Nota: al momento della scrittura di questo articolo, sfortunatamente, l’operazione JOIN non \u00e8 supportata per PartiQL in AWS Glue Elastic Views, quindi abbiamo optato per testare alcune operazioni matematiche e logiche, oltre a convalidare tutti i passaggi per sincronizzare la tabella DynamoDB con il bucket S3.<\/em><\/p>\n\n\n\n Per il nostro esempio, abbiamo deciso di utilizzare un semplice set di dati sugli avvistamenti UFO<\/a>. Vogliamo mettere questo file CSV in una tabella DynamoDB, come detto prima, e applicare alcune operazioni di filtraggio sui campi di latitudine e longitudine, o anche citt\u00e0. Il risultato verr\u00e0 utilizzato per rispondere alla seguente domanda di esempio: “In che modo gli avvistamenti UFO variano a seconda delle diverse zone?”. Vogliamo creare la tabella per DynamoDB, e per fare questo, abbiamo definito un semplice script, in SageMaker Studio, che si sobbarchi l\u2019operazione per noi.<\/p>\n\n\n\n Fondamentalmente andiamo a leggere i dati dal file CSV usando Pandas, convertiamo le righe in JSON, ma prima di farlo, aggiungiamo anche una colonna “hash” chiamata id<\/strong>, perch\u00e9 DynamoDB ha bisogno di una chiave primaria per ogni item.<\/p>\n\n\n\n Il set di dati sugli UFO presentava anche alcuni problemi che dovevano essere risolti: l\u2019header “longitudine” aveva degli spazi da rimuovere e le colonne di latitudine e longitudine dovevano essere convertite in formato stringa rimuovendo le voci NaN.<\/p>\n\n\n\n Infine, abbiamo utilizzato boto3 per creare una tabella corrispondente al CSV.<\/p>\n\n\n\ndynamodb = boto3.resource(‘dynamodb’)\ntable = dynamodb.Table(‘article_ufo_sightings’)\nwith table.batch_writer() as batch:\n…\nbatch.put_item(Item=record)\n\n\n\n Il codice completo pu\u00f2 essere esplorato qui<\/a>.<\/p>\n\n\n\n Nota: avremmo potuto utilizzare AWS Glue anche per questa attivit\u00e0, inserendo il file CSV in un bucket S3 di origine, utilizzando poi Glue Crawler per importare i dati, ma poich\u00e9 abbiamo gi\u00e0 trattato i lavori ETL con questo servizio in altri <\/em>articoli,<\/em><\/a>abbiamo optato per una soluzione pi\u00f9 semplice non essendo questo il fulcro dell’esempio.<\/em><\/p>\n\n\n\n Siamo semplicemente andati alla console DynamoDB, abbiamo cliccato su “create table” e abbiamo utilizzato le semplici impostazioni segnate in immagine. Una nota per\u00f2: applichiamo la modalit\u00e0 di capacit\u00e0 on-demand<\/strong> per velocizzare la generazione della tabella.<\/p>\n\n\n Aggiungiamo id<\/strong> come chiave primaria per la tabella UFO sightings <\/p>\n\n\n\n Prima di generare la vista, dovevamo aggiungere la tabella DynamoDB come sorgente in AWS Glue Elastic Views; per farlo, siamo andati alla console principale, abbiamo selezionato \u201cTables\u201d a sinistra e cliccato su \u201cCreate Table\u201d. Quindi abbiamo selezionato la nuova tabella DynamoDB, generata nei passaggi precedenti.<\/p>\n\n\n Il passaggio successivo \u00e8 stato applicare alcuni filtri per creare il nostro set di dati di destinazione finale, dipendente dalla vista. <\/p>\n\n\n\n Andando sulla scheda “Views” sul lato sinistro della console ne abbiamo creata una nuova. Qui ci \u00e8 stata presentata la possibilit\u00e0 di scrivere codice PartiQL personalizzato: esattamente quello che volevamo!<\/p>\n\n\n\n Abbiamo aggiunto il seguente codice nell’editor per abilitare la nostra vista materializzata:<\/p>\n\n\n\n Abbiamo anche dovuto scrivere tutti gli attributi che volevamo esportare nei file di parquet di destinazione (sembra che AWS Glue Elastic Views generi batch di file di parquet nella directory di output).<\/p>\n\n\n\n Come il lettore pu\u00f2 osservare dal codice sopra, abbiamo evitato di richiedere apposta informazioni utili: volevamo mostrare che \u00e8 possibile modificare la vista in tempo reale dopo che la materialized view \u00e8 stata creata.<\/p>\n\n\n\n Al momento della scrittura di questo articolo, S3 \u00e8 una delle tre opzioni disponibili come target, insieme a ElasticSearch e Redshift. Nel nostro caso S3 \u00e8 la destinazione ideale, in quanto vogliamo che il set di dati finale venga consumato da SageMaker. <\/p>\n\n\n\n Siamo andati dentro la View e abbiamo cliccato su \u201cMaterialized View\u201d, quindi abbiamo selezionato \u201cGlue EV\u201d come supporto per sbloccare \u201cS3\u201d come target: l\u00ec abbiamo aggiunto il bucket \u201carticle-ufo-materialized-views\u201d e selezionato default come crittografia; abbiamo aggiunto un ruolo IAM adatto per l’esecuzione. <\/p>\n\n\n\n Il ruolo pu\u00f2 essere creato utilizzando l’editor per ruoli e policy di AWS<\/strong>, tenendo per\u00f2 a mente che, una volta creato, si dovr\u00e0 modificare la trust relationship<\/strong> con il seguente codice per abilitare il ruolo IAM, altrimenti non saremo in grado di vedere il ruolo nel selettore:<\/p>\n\n\n\n Qui abbiamo invece uno screenshot con i parametri utilizzati:<\/p>\n\n\n Una volta creata, la vista deve essere attivata per sincronizzarsi con il bucket S3; per farlo, siamo andati sia nella tabella che nella vista che avevamo creato, e abbiamo cliccato su \u201cAttiva\u201d nel loro pannello di dettaglio.<\/p>\n\n\n\n Dopo un paio di minuti dall’attivazione, il bucket S3 \u00e8 stato riempito con i dati risultanti!<\/p>\n\n\n Fatto interessante: appena prima di attivare la visualizzazione, il servizio si \u00e8 lamentato del fatto che alcuni campi non fossero compatibili con il target di output e ci ha dato la possibilit\u00e0 di modificare la visualizzazione al volo con un editor in linea, questo \u00e8 quello che abbiamo fatto per castare “Latitudine” e “Longitudine” a numero intero:<\/p>\n\n\n I dati sono ora collegati direttamente con il nostro bucket S3, quindi qualsiasi modifica apportata alla tabella si riflette direttamente dopo alcuni secondi. Fondamentalmente \u00e8 come avere un Glue Crawler che funziona su richiesta, che si accende e si spegne quando necessario, e senza intervento umano.<\/p>\n\n\n\n Volevamo dimostrare che \u00e8 possibile modificare i dati ottenuti dalla tabella DynamoDB in qualsiasi momento, per questo abbiamo iniziato salvando “file parquet incompleti” come il lettore pu\u00f2 osservare qui:<\/p>\n\n\n\n Per modificare il nostro set di dati finale dovevamo prima “disattivare” la vista materializzata. Successivamente, \u00e8 stato possibile definire una nuova vista Materializzata sullo stesso target aggiungendo pi\u00f9 colonne. Si noti inoltre che, se si dispone di pi\u00f9 visualizzazioni dipendenti l’una dall’altra, \u00e8 necessario disattivarle ed eliminarle nell’ordine corretto. Forse questa operazione diventer\u00e0 meno macchinosa al momento del rilascio ufficiale. <\/p>\n\n\n\n Abbiamo modificato la definizione originale della vista materializzata aggiungendo pi\u00f9 colonne:<\/p>\n\n\n\n Nonostante il processo non proprio lineare, queste operazioni hanno richiesto meno di 5 minuti e i nuovi dati sono stati presto resi disponibili nel bucket S3 corretto:<\/p>\n\n\n\n Ovviamente se le modifiche si trovano nella tabella originale e non nella vista, gli aggiornamenti sono completamente \u201cseamless\u201d come ci si aspetterebbe.<\/p>\n\n\n\n Un altro promemoria: essendo l’interfaccia ancora in fase di anteprima, consigliamo di evitare di lanciare molte operazioni in poco tempo, poich\u00e9 abbiamo riscontrato diversi bug legati a \u201crace condition\u201d non ancora gestite correttamente.<\/p>\n\n\n\n Per verificare che il datasource target sia sfruttabile per lavori di machine learning, abbiamo anche preparato un semplice Jupiter Notebook di test per SageMaker, applicando alcune semplici analisi di correlazione sul data lake creato. Tutto questo si pu\u00f2 vedere in dettaglio nel notebook<\/a>. L’idea era di verificare se esiste una sorta di correlazione tra luoghi, citt\u00e0 e avvistamenti UFO e, sulla base dei dati di esempio, provare a fare alcune semplici inferenze. Ulteriori informazioni su come utilizzare SageMaker per fare inferenza sono state trattate in questo articolo.<\/a><\/p>\n\n\n\n Siamo giunti alla fine di questo viaggio nelle meraviglie di AWS Elastic Views, quindi \u00e8 il momento di riassumere ci\u00f2 che abbiamo imparato finora.<\/p>\n\n\n\n Questo servizio AWS si rivela prezioso quando si tratta di lavorare con molte origini dati, soprattutto se di diversa natura, in quanto recupera e interroga tutti i dati con un linguaggio compatibile SQL (PartiQL), evitando la creazione di molti lavori ETL Glue complessi.<\/p>\n\n\n\n \u00c8 perfetto in tutte quelle situazioni in cui \u00e8 necessario combinare dati legacy e nuovi<\/strong>, poich\u00e9 di solito risiedono, come da best practice, su diverse origini dati: quelle pi\u00f9 economiche per gli accessi poco frequenti e quelle con bassa latenza per i nuovi dati.<\/p>\n\n\n\n![\"AWS](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image8.png\")
<\/figure><\/div>\n\n\n\n
Come funziona<\/h2>\n\n\n\n
![\"AWS](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image13-1024x424.png\")
Usare SQL come mezzo per creare una view<\/h4>\n\n\n\n
Copiare autonomamente da una fonte dati ad un datalake target<\/h4>\n\n\n\n
Mantenere i dati nella destinazione sempre aggiornati, automaticamente<\/h4>\n\n\n\n
Avvisare quando avviene un cambiamento nei dati di un data store sorgente<\/h4>\n\n\n\n
Serverless<\/h4>\n\n\n\n
Registrarsi per la preview gratuita<\/h2>\n\n\n\n
![\"AWS](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image5-1-1024x299.png\")
![\"AWS](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image3-1-1024x185.png\")
Entriamo nel vivo del nostro test<\/h2>\n\n\n\n
![\"AWS](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image11-1024x394.png\")
Panoramica<\/h3>\n\n\n\n
Dataset<\/h3>\n\n\n\n
Questo \u00e8, ovviamente, solo un semplice esempio, non ha implicazioni pratiche a parte dimostrare alcune funzionalit\u00e0 di AWS Glue Elastic Views.<\/p>\n\n\n\nImportare i dati in DynamoDB<\/h3>\n\n\n\n
![\"a](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image9-1024x127.png\")
for record in json_list:\n if record['longitude '] and record['latitude']:\n record['id'] = sha256(str(record).encode()).hexdigest()<\/code><\/pre>\n\n\n\nCreare la tabella in DynamoDB<\/h3>\n\n\n\n
![\"DynamoDB](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image10-1024x413.png\")
Creare una Materialized View dalla tabella<\/h3>\n\n\n\n
![\"Tabella](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image1-1-1024x180.png\")
SELECT id, Latitude, Longitude FROM article_ufo_sightings.article_ufo_sightings<\/code><\/pre>\n\n\n\nInviare i dati ad Amazon S3<\/h3>\n\n\n\n
\"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Service\": [\n \"materializedviews.amazonaws.com\"\n ]\n },\n \"Action\": \"sts:AssumeRole\"\n }\n ]\n}<\/code><\/pre>\n\n\n\n![\"Materialized](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image4-1-1024x907.png\")
![\"ufo](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image12-1024x463.png\")
![\"Applichiamo](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image2-1-1024x118.png\")
<\/figure><\/div>\n\n\nModifichiamo i dati su S3<\/h3>\n\n\n\n
![\"Dataset](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image7.png\")
SELECT id,cast(City as string),cast(State as string),cast(Shape as string),cast(Latitude as integer),cast(Longitude as integer) FROM article_ufo_sightings.article_ufo_sightings;<\/code><\/pre>\n\n\n\n![\"Dataset](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2021\/04\/image6.png\")
Ora possiamo farci del Machine Learning!<\/h3>\n\n\n\n
Referenze<\/h2>\n\n\n\n
\n
Per concludere<\/h2>\n\n\n\n