Nel progettare l’architettura, illustrata in Figura 5.1, si è cercato di ricostruire il
più fedelmente possibile, l’architettura di un sistema Big Data. Allo stesso tempo si è cercato di disaccoppiare servizi e responsabilità in modo da rendere il sistema
modulare e facilmente espandibile, sia verticalmente che orizzontalmente.
Questo capitolo vuole semplicemente introdurre i tre nodi del cluster con i relativi ruoli all’interno del sistema, i capitoli successivi si occuperanno di analizzare nel det-
taglio i servizi strettamente legati al caso d’uso e all’applicazione delle metodologie DevOps.
Il Cluster è implementato su Google Cloud Platform, grazie al servizio di
Compute Engine (CE).
5.1.1
Cloudera VM
Configurazione Hardware CE dotata di 4 vCPU, 18 GB RAM, 35GB HDD permanente standard, Centos-7-v20171129, zona us-east1-b. La macchina è la più
Figura 5.1: Architettura del sistema
potente del cluster, essendo il nodo master del sistema è stato dotato di maggiori capacità in modo da poter gestire comodamente i processi di Cloudera CDH.
Ruolo
Cloudera VM è pensata per ospitare il Data Warehouse del sistema implementato
grazie alla piattaforma Cloudera. Il Data Warehouse è fisicamente e logicamente composto da un Data Lake e un Data Mart, implementati con tecnologie differenti. Il
CDH offre inoltre servizi accessori, quali un database PostgreSQL e Sqoop1 utilizzati nelle fasi di Ingestion e Estraction Batch.
Hive Data Lake
Nel Data Lake, realizzato come un insieme di tabelle Hive, vengono memorizzati i dati nella loro forma originale, senza preoccuparsi di pulizia o trasformazioni. Questo
datastore è pensato per accogliere tutti i dati relativi all’organizzazione senza fare distinzioni riguardo il singolo applicativo. Seppur non effettivamente necessario per
il funzionamento del caso d’uso, si è deciso di mantenerlo nell’ottica di definire un’architettura il più possibile generale. L’architettura di Hive, come già discusso,
permette di memorizzare ed accedere ai dati tramite un’interfaccia SQL-like; essendo un metodo prossimo al formato di memorizzazione originale dei dati, ho valutato
che potesse garantire il minimo intervento in termini di gestione.
Kudu Data Mart
Il Data Mart invece conterrà i dati relativi ad una singola applicazione, in questo caso tutto il necessario ad implementare ed utilizzare il Raccomandato di Film. Tali dati
sono più raffinati di quelli contenuti nel Data Lake, due processi ETL si occupano infatti della pulizia e trasformazione delle informazioni in modo da renderle adatte
alla successiva analisi.
La scelta di utilizzare un Data Mart Kudu è derivata dalla necessità di memo- rizzazione ed accesso, rapido ed efficiente, dei campi di tipo Double dei Ratings. Grazie alla memorizzazione in formato colonnare di Kudu è possibile ottimizzare l’elaborazione minimizzando il numero di accessi al datastore.
Database PostgreSQL
Cloudera CDH include, nella sua configurazione standard, un database PostgreSQL versione 9.2. Questo tipo di RDBMS, seppure datato rispetto agli altri sistemi di
gestione di database, offre una maggior robustezza e una ricca documentazione, ren- dendolo uno strumento comodo da utilizzare e facile da interfacciare. Lo script Py-
thon DBFeeder.py si interfaccia con tale database per simulare l’interazione utente con un sistema a monte.
5.1.2
DevOps Worker
Configurazione Hardware CE n1-standard-2 dotata di 2 vCPU e 7.5 GB RAM, 40GB HDD permanente standard, Centos-7-v20171129, zona us-east1-b. Si è voluto utilizzare una macchina dalle caratteristiche standard per mettere in luce il vantaggio
dello scaling orizzontale.
Ruolo
Il DevOps Worker rappresenta un Edge Node, dedicato alla computazione all’interno del cluster. Su di esso vengono eseguiti i quattro processi principali di elaborazione
e tutto il necessario alla loro esecuzione.
Processi
I processi, analizzati nel prossimo capitolo, vogliono mostrare le quattro principali combinazioni di elaborazione all’interno di un sistema Big Data. Per garantirne
l’esecuzione, il nodo è dotato di Spark 2.2.0 ed SBT 1.0.3, utilizzato per la gestione delle dipendenze.
Servizi
• Confluent Kafka è utilizzato dal processo di ETL Real Time per estrarre
i dati memorizzati nel database PostgreSQL, collocato in remoto sul nodo Cloudera VM.
• Node_Exporter e DevOpsMetrixExposer sono due daemon che espongo- no metriche di interesse per sistema di Continuous Monitoring. Il primo espone
metriche relative allo stato hardware del nodo, il secondo mette a disposizione informazioni riguardo l’esecuzione dei processi.
5.1.3
Big Brother
Configurazione Hardware CE n1-highmem-2 dotata di 2 vCPU e 13 GB RAM, 40GB HDD permanente standard, Centos-7-v20171129, zona us-east1-b. Pur non richiedendo grosse capacità computazionali, la macchina necessità di più memoria
di un semplice edge-node a causa del grande numero di servizi installati.
Ruolo
Il nodo Big Brother è pensato per essere un nodo di supporto e controllo del cluster, in esso sono collocati tutti i servizi propri del processo di sviluppo devops-based,
oltre ai tool necessari al Provisioning, Orchestration e Instrumentation del cluster.
Servizi
• Il Pushgateway permette ai processi batch di trasmettere metriche in moda- lità push e white-box;
• Il Prometheus Server effettua lo scraping delle metriche esposte dagli Expo- ser, presenti sia sul DevOps Worker sia sul Big Brother stesso, dal Pushgateway
e dal servizio Machine Learning Real Time di raccomandazione;
• Grafana offre un’interfaccia a dashboard utile per monitorare le metriche raccolte ed attivare allarmi in caso di necessità;
• Ansible permette di gestire il Provisioning dei nodi del cluster, non solo in termini di espansione ma anche di monitoring dello stato, oltre al deploy sicuro
dei processi in produzione;
• Terraform, associato ad Ansible, gestisce l’espansione orizzontale del cluster
secondo la necessità del caso;
• Jenkins, sfruttando l’interfaccia Blue Ocean, mette a disposizione il server
di Continuous Integration e Continuous Deployment;
• Spark 2.2.0 e SBT 1.0.3 contribuiscono a creare un ambiente di sviluppo
identico a quello di produzione, sono utilizzati all’interno della pipeline di CD per effettuare i test e la compilazione dei processi.
5.1.4
Servizi Esterni
Per completezza sono mostrati anche Slack, utilizzato per la gestione delle comu-
nicazioni intra-team e la notifica di eventi, e GitHub, Version Control System utilizzato per il Continuous Integration del codice implementato.