Alla scoperta di S/4HANA

La piattaforma HANA: comprendere la memoria

Per comprendere HANA è necessaria una breve considerazione rispetto al funzionamento della memoria in un computer.

Così come molte altre applicazioni, ERP era stato sviluppato in base a ciò che poteva essere fatto utilizzando la tecnologia disponibile a quel tempo.
I vincoli principali erano il costo della potenza di elaborazione e dell’immagazzinamento.
Le limitazioni legate all’hardware portarono a limitazioni nella logica del software, che portarono a loro volta ai molteplici problemi di cui abbiamo già discusso nei capitoli precedenti. 

Tuttavia, considerando la legge di Moore, gli aumenti nella potenza di elaborazione e di immagazzinamento e la riduzione dei costi di hardware offrirono a SAP l’opportunità di ripensare l’architettura di ERP. Questo ci porta all’arrivo di HANA. 

HANA è il termine utilizzato per riferirsi a un nuovo database il cui sviluppo era stato guidato da uno dei fondatori di SAP.

“HANA” infatti sta per:

• Hasso’s New Architecture (proprio dal nome di Hasso Plattner, uno dei cinque fondatori di SAP)
• in alternativa “High-Performance Analytical Application”

 È possibile conoscere HANA dallo stesso Hasso sulla piattaforma per la formazione dell’Hasso Plattner Institute per lo sviluppo dei sistemi e software: 

https://open.hpi.de/courses?lang=en

Ci sono tre caratteristiche chiave che consentono alla piattaforma HANA di risolvere i problemi incontrati da ERP e BI che stavamo affrontando, e sono:

• Elaborazione in memoria
• Gestione dei database a colonne e compressione dei dati
• Elaborazione parallela 

Dedicheremo un approfondimento ai primi due argomenti citati per comprendere meglio cosa sia HANA. Il terzo, ossia l’elaborazione parallela, è un concetto piuttosto comune nei computer moderni, che possono utilizzare molteplici processori in simultanea sulla stessa operazione.

Come funziona la memoria

Per cominciare la spiegazione di come HANA utilizzi la memoria prendiamo come esempio un normale computer desktop. La memoria può essere categorizzata in tre tipologie:

• Memoria ausiliaria: la memoria più ampia e meno costosa. Può essere su disco magnetico o su unità a stato solido. I dati sono conservati quando il sistema è spento. Scrivere o leggere dati è estremamente lento
• Memoria principale: composta principalmente dalla RAM, più costosa ma molto più veloce della memoria ausiliaria. I dati vanno persi quando l’alimentazione è spenta
• Memoria cache: un piccolo quantitativo di memoria molto veloce vicino al processore che contiene i dati utilizzati dal processore stesso. 

Il fattore principale nella determinazione della velocità di elaborazione di un computer è quanto velocemente può leggere e scrivere sulla memoria. Se il processore ha bisogno dell'accesso alla memoria ausiliaria allora il processo sarà molto lento. 

R/3 non funziona su desktop, funziona su server. A prescindere dalla terminologia IT, un server è un computer nello stesso modo in cui un desktop è un computer. 

Per questo motivo possiamo considerare R/3 ERP come un grande computer con enormi volumi di dati, una delle ragioni principali per cui non può essere utilizzato per analisi dati avanzate è il tempo che richiede per recuperare i dati dalla memoria ausiliaria.

Elaborazione in-memory con HANA

Mentre la tecnologia diventa più avanzata e i prezzi delle componenti scendono, la memoria principale è ora disponibile a un costo tale per cui può essere utilizzata per un volume di immagazzinamento che in precedenza
era possibile soltanto nella memoria ausiliaria.

Per citare direttamente SAP: “ SAP HANA funziona su un processore multi-core con comunicazione veloce tra i core del processore e i terabyte di dati contenuti nella memoria principale. Con SAP HANA tutti i dati sono disponibili nella memoria principale e questo evita la riduzione delle prestazioni dell'I / O del disco (ovvero la lettura / scrittura sulla memoria ausiliaria). 

In parole povere il set di dati completo all’interno di ERP è archiviato in ciò che noi consideriamo RAM, sui nostri desktop o portatili, ed è facilmente accessibile dal processore.
Con HANA non abbiamo bisogno di memoria ausiliaria per le operazioni quotidiane. 

Si noti tuttavia che essa viene ancora utilizzata per il backup / ripristino di emergenza, ad esempio in caso di interruzione dell’alimentazione.

Immagazzinamento dati a colonne con HANA

Oltre a in-memory HANA applica metodi di gestione dei database che sono più efficaci nella compressione dei dati.
E più i dati sono compressi più velocemente il sistema può funzionare.

Tradizionalmente un database OLTP manterrà i dati ordinati su riga.
Paragoniamo l'archiviazione su riga con un metodo alternativo: l’archiviazione a colonne. Ti accorgerai facilmente che nell’ordinamento a colonna molti valori possono essere duplicati uno vicino all'altro. Intuitivamente possiamo vedere una sistemazione dei dati a colonna come molto più semplice da comprimere. 

La compressione è un argomento piuttosto ampio e tecnico, ma per farla semplice immagina una colonna per “città”: in una tabella di indirizzi avremo centinaia se non migliaia di dati come ad esempio “Londra". Se questo è il caso non abbiamo bisogno di inserire Londra ogni volta, possiamo invece organizzare tutte le righe che riportano Londra come città e questo significa che se c'è una domanda o ricerca per Londra, l'applicazione non ha bisogno di cercare attraverso ogni riga per individuare i risultati. 

Tenendo in considerazione la memoria interna con l'immagazzinamento a colonna, la piattaforma HANA fornisce un database che può operare molto più velocemente rispetto alle opzioni per i database utilizzate in R/3 o Business Suite 7 o in ogni tradizionale sistema OLTP.
Questo è un punto piuttosto importante:

• Non abbiamo più bisogno di separare applicazioni OLTP e OLAP da database e applicazioni differenti. Un singolo database o applicazione HANA può svolgere entrambi i tipi di operazioni in modo efficace. Questa è un'opportunità per semplificare notevolmente l'hardware, l'architettura tecnica e l'architettura del database. 

• Possiamo semplificare le applicazioni della business suite. Un esempio: poiché i sistemi OLTP erano generalmente lenti nella lettura e analisi dei dati si riscontravano spesso tabelle con subtotali e totali che venivano aggiornati una volta processate le transazioni. Queste tabelle possono ora venir semplificate o rimosse, insieme a molti altri elementi di complessità.