Architectural design

LŠultimo aspetto che ci rimane da trattare, parlando della piattaforma tecnologica scelta per il suddetto progetto (Open Data Cube), riguarda i servizi principali che compongono il sistema. Come abbiamo gi‘a detto, la precedente fase di selezione dei componenti di Open Data Cube ‘e propedeutica alla presente fase dal momento che ogni strumento che abbiamo scelto di inglobare nel sistema ha i suoi moduli da mandare in esecuzione. Per comprendere quali sono i principali servizi del sistema ci siamo serviti della documentazione ufficiale di ODC, di articoli scientiĄci redatti su di esso e, inĄne, di unŠapprofondita analisi tecnica sui processi necessari al sistema per lŠesecuzione. A tal proposito, di seguito, verranno elencati i servizi del sistema, raggruppati per area di competenza:

• ODC Web UI : la componente di interfaccia Web di Open Data Cube si basa sullŠesecuzione di diversi processi, quali il processo omonimo dellŠinterfaccia web (denominato ODC UI, dove UI sta per ŞUser InterfaceŤ), Django, Celery e Redis.

Di seguito verranno elencati i suddetti servizi e, per ciascuno di questi, verranno descritte le singole funzionalit‘a; questi servizi sono:

Ű ODC UI : questo servizio ‘e il principale modulo del sistema che viene mandato in esecuzione. Esso permette allŠutente Ąnale di interfacciarsi con il sistema e, come abbiamo detto precedentemente, consente a questŠultimo di selezionare aree di interesse ed, inoltre, di visualizzare sia i dati presenti nel sistema che lŠoutput di una determinata analisi. UnŠulteriore osservazione da fare sul servizio ODC UI ‘e che, a livello di cronologia di esecuzione del sistema, ‘e quello che viene tirato su per ultimo, tra i tre moduli della UI proprio perch´e

‘e dipendente dagli altri due (Django e Redis).

A livello tecnico, la funzionalit‘a che ha questo servizio ‘e quella di elaborare le richieste degli utenti (effettuate attraverso la componente graĄca) per poi, attraverso Django, trasformarla in query ed inviarla a Celery e Redis per la gestione della stessa.

Ű Django: questo modulo rappresenta il ŞmotoreŤ dellŠinterfaccia graĄca ed ha il compito di ricevere le richieste dellŠutente ed inviare le risposte. A livello di funzionalit‘a, esso si serve di due tecnologie fondamentali per il sistema, deno-minate Celery e Redis, per gestire e smistare le richieste e, conseguentemente, elaborare le risposte da mandare indietro allŠutente che ne ha fatto richie-sta. Django si compone anche di un database, gestito attraverso il DBMS PostgreSQL, che ha il Ąne di memorizzare principalmente gli account degli utenti che si interfacciano con la UI di ODC.

In questo contesto, ‘e importante sottolineare che il web framework Django ‘e il runserver utilizzato nativamente dalla UI di ODC; dunque, questo ‘e il caso di una PoC. UnŠimplementazione professionalmente pi‘u avanzata potrebbe prevedere lŠutilizzo di un Web server migliore di quello di Django.

Ű Redis e Celery: sono due moduli che lavorano congiunti e che gestiscono in maniera asincrona i task di unŠapplicazione Django. Celery ‘e un pacchetto software basato su Python che permette lŠesecuzione di carichi di lavoro com-putazionali asincroni guidati da informazioni contenute nei messaggi che sono prodotti nel codice dellŠapplicazione Django destinati a una coda di lavoro (Celery appunto). ‘E fondamentale sottolineare il fatto che Celery gestisce il tutto in maniera asincrona, ci‘o vuol dire che il sistema continua lŠesecuzione e non sta ad aspettare una risposta (sincrona, appunto). Celery viene spesso utilizzato, come nel presente caso, in combinazione con Redis (acronimo di ŞRemote Dictionary ServerŤ), una soluzione di archiviazione che funge da broker di messaggi. Redis, in particolare, ‘e un database NoSQL (precisa-mente del tipo key-value store) open source che, nel nostro sistema, viene utilizzato sia per memorizzare nella coda delle attivit‘a di Celery i messaggi che descrivono il lavoro da svolgere, sia per memorizzare i risultati che escono dalle code di Celery.

• Database: componente fondamentale del sistema che rappresenta il database di Open Data Cube. Esso ha il compito di memorizzare i dati satellitari ed ‘e gestito dal DBMS PostgreSQL; in particolare, qui viene chiamata in causa unŠestensione di questŠultimo denominata PostGIS (dove GIS sta per ŞGeographic Information SystemŤ). PostGIS aggiunge al DBMS PostgreSQL vari tipi, come dai geome-trici, dati geograĄci, raster etc. Esso, inoltre, aggiunge funzioni, operatori, tipi e miglioramenti agli indici che si applicano a questi tipi spaziali che aumentano la potenza del DBMS PostgreSQL di base, rendendolo un sistema di gestione di database spaziali veloce, robusto e ricco di funzionalit‘a.

UnŠaltra funzionalit‘a che ‘e stata ritenuta come necessaria dai requisiti di proget-to ‘e lŠaspetproget-to riguardante la sicurezza; PostgreSQL, a tal proposiproget-to, implementa sia un sistema di controllo degli accessi che un sistema di controllo delle identit‘a (basato sul meccanismo di autenticazione).

• Jupyter Notebook: questo servizio viene implementato attraverso JupyterLab, estensione del progetto Jupyter che mette a disposizione dellŠutente un ambiente di sviluppo aggiornato ed interattivo, basato sul Web, per notebook, codici e dati. La sua interfaccia Ćessibile consente agli utenti di conĄgurare e organizzare i Ćussi di lavoro in ambito data science e in molti altri ambiti. Un design modulare invita le estensioni ad espandere e arricchire la funzionalit‘a. Anche qui, come per il database e per lŠinterfaccia utente, ‘e stato posto un focus sulla parte

di sicurezza; anche JupyterLab implementa un sistema di sicurezza attraverso lŠautenticazione, basato su una chiave segreta che ‘e indispensabile per accedere ai notebook pre-esistenti, oppure per crearne di nuovi.

Questo servizio non ha bisogno di dialogare con la componente Web, dal momen-to che viene messo al servizio degli analisi e dei data scientist, piutmomen-tosmomen-to che delle risorse business, ma ha bisogno di interagire con il servizio di database di ODC.

Infatti, ‘e necessario deĄnire un Ąle di conĄgurazione che sar‘a indispensabile, in fase di programmazione, per creare le istanze di Open Data Cube.

A valle del lavoro di ricerca, studio ed analisi del sistema precedentemente de-scritto, sono stati individuati i servizi appena presentati e, inoltre, le varie interazio-ni tra questi ultimi. Grazie a questa fase ‘e stato possibile ricostruire lŠarchitettura del sistema, basata sulle componenti di ODC precedentemente scelte. In Figura 3.3 viene mostrata la componente architetturale del sistema formata da attori che in-teragiscono con essa, servizi fondamentali e interazioni fra questi; nellŠimmagine, attraverso la numerazione e le lettere, vengono ricostruiti tre possibili work-Ćow di processo derivanti dallŠinterazione fra lŠutente Ąnale ed il sistema.

Figura 3.3.Architettura del sistema Open Data Cube con i vari servizi

Come illustrato nella Ągura 3.3, i work-Ćow contrassegnati con le lettere ŞaŤ e ŞbŤ sono avviabili dal decision maker che si interfaccia con la UI di ODC, mentre quello contrassegnato con la lettera ŞcŤ ‘e il possibile work-Ćow avviabile dal data scientist attraverso il servizio Jupyter. A partire da questŠarchitettura ‘e facilmente intuibile che le frecce continue simboleggiano delle richieste, mentre le frecce tratteggiate simboleggiano le risposte che vengono ritornate a fronte (cio‘e, in risposta) di una richiesta ricevuta.