BigData & Graphs in Rome OrientDB & Big Data:storie di vita vissuta Da un caso di successo a un futuro che “spacca” Un backstage di un caso di successo con un occhio critico ai problemi avuti, ma con la consapevolezza di un futuro brillante. Il riassunto della nascita di una suite di business intelligence. By Luca Bianconi @LucaBianconi74

1. OrientDB & Big Data:
storie di vita vissuta
Da un caso di successo
a un futuro che “spacca”
BigData & Graphs in Rome

2. Luca Bianconi
Senior Consultant
Partner Italiano
di Orient Technologies UK
2

3. Un po’ di storia
• Nata nel 2004 come technological company di
AssetManagement, AssetData si impone sin da subito
come leader in Italia per lo sviluppo e l’integrazione delle
tecnologie open source più innovative ed evolute:
– Java
– Roma<Meta>Framework
– AngularJS
– OrientDB
• Ha partecipato a diversi progetti per lo sviluppo e la
diffusione di software open source con il supporto della
Comunità Europea
• Leader nello sviluppo di soluzioni HR
• Acquisita nel 2012 da leader nel settore della
somministrazione di lavoro (fatturato internazionale >> €
800M)
3

4. La nuova direzione
Trick
StressCorrelato
SKY
Apprendistato
4

5. La richiesta
Sviluppare un sistema di BI (real time)
per le VLT di una famosa società italiana
di gaming
5

6. Cosa sono le VLT
Video Lottery Terminal
6

7. Il mondo delle VLT
• Fornitori: Gtech, Novomatic, etc.
• Concessionari: Lottomatica, SNAI, SISAL,
etc.
• Macchine: VLT, AWP, etc.
• Distribuzione geografica: Aree, Regioni,
Province, …, Sale
• Granularità dati: Sala, Gioco, VLT
• Frequenza dati: singola giocata o
giornaliera
7

8. Qualche numero
• 5.000 Sale
• 40.000 VLT
• 30 Giochi
• 10 Concessionari
• 9 Flussi di dati a concessionario
• > 60.000.000 di record al giorno per le
concessionarie più grandi
8

9. Cosa abbiamo trovato
• DB2
• 4 ore per l’estrazione dei file di un singolo
concessionario (size = 2.5GB)
• Excel e Access
• 3 persone full x analizzare i dati
• Centinaia di mail a settimana per il board
• Dati destrutturati…
9

10. Esigenze
• BIG DATA
– MILIARDI DI RECORD
• PERFORMANCE
– TEMPI DI RISPOSTA IMMEDIATI
• WEB BASED
– RAGGIUNGIBILE DA INTRANET/INTERNET
• GESTIONE UTENTI
– PROFILAZIONE RUOLI
• REPORT, GRAFICI E DATI MODIFICABILI
– ALTA INTERATTIVITA’
10

11. L’implementazione
Serve un multi-model graph database!
11

12. C’è tanto da fare
Ok abbiamo il DB: Orient 1.3. E adesso?
12

13. Da Orient a OrientBI
CSV ETL (Java)
OrientDB
Istruzioni in JS
Front end e Back end
Html + JS + Bootstrap
Command + JS
Report
Orient Processing LAnguage
JSON
JSON
JS (orientdb-bi)
13

14. Architettura finale
PLATFORM 1
…
PLATFORM 2
PLATFORM 4
OrientBI
GRAFICI
REPORT
SCHEDE
MODIFICABILI
PLATFORM 3
14

15. La lista della spesa
•ETL
•Back end
•Front end
•Report
•Applicazione
15

16. ETL parte 1
• I file si trovano all’interno di una cartella denominata
‘’template’’
• I file hanno estensione: *.template
• Nel file orientdb-server-config.xml c’è il seguente codice
relativo all’etl:
…………………………….
16

17. ETL parte 2
‘’HEADER’’
@class Sala
[@save disabled]
@field sistema link @join Sistema.id_sistema_aams
@field seriale_vlt string @trim
@field codice_aams string @index
@field regione skip
@field metri_quadri integer
@field data_estrazione date @format MM/dd/yyyy
@index Sala.sistema_seriale UNIQUE sistema seriale_vlt
17

18. ETL parte 2
‘’BODY’’
@onBeforeFile {{{
…
}}}
@onBeforeLine {{{
@onAfterFile {{{
@onAfterLine {{{
…
[record.save();]
}}}
18

19. ETL e linguaggi
• Rhino
• Se viene utilizzato Java 8 il motore sarà
Nashorn
– Prestazioni equiparabili a Google V8
19

20. ETL esempi di codice 1
@onBeforeLine {{{
var record = task.getVariable("currentRecord");
var lastDate = task.getVariable("lastDate" );
var currentDate = record.field("data_contabile");
if( lastDate == null || !lastDate.equals( currentDate ) ) {
var deleted = db.command("delete from
DatiContabiliVLTGioco where data_contabile = ? and sistema =
?", currentDate, sistema);
task.setVariable("lastDate", currentDate );
}
}}}
20

21. ETL esempi di codice 2
// GROUP MONTLY DATA
var dayOfTheMonth =
finalDate.get(java.util.Calendar.DAY_OF_MONTH);
var firstOfMonth =
Packages.com.orientechnologies.orient.core.util.
ODateHelper.getDatabaseCalendar();
…
groupDatiSala(firstOfMonth.getTime(), maxDate,
"DatiContabiliSala_mese", sistema);
21

22. 1° POC
• >> 1000 rec/sec
• Ok ‘’It works!’’
• Come vedo se ha importato i dati?
• La console è scomoda… usa Studio!
22

23. Il primo Studio
23

24. Il secondo Studio
24

25. Boe dammi una Duff!
25

26. E’ sufficiente?
• 120.000.000 (record) ÷ 1.200
(record/secondo)
• + o - fanno 28 ore…
• E il real time?
Darvaza
Turkmenistan
Porta dell’inferno
26

27. La soluzione
Dove non arriva JS arriva Java
Modifica dell’header del template e
implementazione dell’import in Java
@class GiocateOrarie
@implementation
it.assetdata.customer.bi.listener.GiocateOrarieImp
orterListener
27

28. Pericolo scampato
• Risultato = 25.000 r/s (1h e ½ per l’import)
28

29. Front end
• I dati ci sono
• Visualizziamoli
29

30. Come è strutturata una pagina
Menu di selezione sale
Menu di selezione temporale
Pulsanti di esecuzione, schedulazione, etc.
[Sezione relativa ai grafici]
Creazione variabili
Invio contestualizzato variabili
Funzioni specifiche
Menu
Risultati
Codice
30

31. Un report tipo
function renderProvince() {
var concessionarie = $("#concessionarie").val();
var aree = $("#aree").val();
var regioni = $("#regioni").val();
var optionsProvince = "<option value='undefined'></option>";
queryResult = db.executeFunction('province',
[ concessionarie, regioni, aree ]);
for ( var r in queryResult.result) {
optionsProvince += '<option value="' + queryResult.result[r].provincia
+ '">' + queryResult.result[r].provincia + '</option>';
}
$('#province').html(optionsProvince);
renderCitta();
}
31

32. Le OFunction
32

33. Come viene generato un report
queryResult = db.process('conc8', [ year, month, week, day,
conc, regioni, pv, citta, sale, aree ], function(result) {
$('#content').html(processResult(result.result[0],
{}));
}, function() {
showErrorMessage(orientServer.getErrorMessage());
});
33

34. Orient Processing LAnguage: OPLA
• Cosè OPLA?
• Creato nel 2012 per essere integrato in
Orient
• E’ un JSON
• E’ un linguaggio di interrogazione del server
in maniera strutturata
• Potente, semplice e leggero
34

35. Alcuni elementi di OPLA 1
• Comprende 8 tipi di blocchi:
– Execute
– Let
– Output
– Table
– Function
– Query
– Script
– Iterate
35

36. Alcuni elementi di OPLA 2
• Inizio tipico
{
"type" : "execute",
"do" : [{
…
36

37. Struttura di report
Ricezione delle variabili
Assegnazione del nome dei campi
[Customizzazione del nome dei campi]
Let
Output Header
Body
Execute Do Function Esecuzione OFunction
Query Esecuzione query
Function Formattazione campi
Script Esecuzione IstruzioniEnd
Output Esecuzione OFunctionFooter
37

38. Acquisizione variabili
{
"type" : "execute",
"do" : [{
"type" : "let",
"value" : {
"debugMode" : "false",
"da" : "${arg0}",
"a" : "${arg1}",
"range" : "${arg2}"
38

39. Esecuzione OFunction
{
"type" : "function",
"function" : "getClassName",
"args" : [
"DatiContabiliSala",
null,
"${range}"
],
"return" : "className"
}
39

40. Esecuzione query
{
"type":"query",
"target":"${className}",
"fields":[
"data_contabile",
"' ' as cipupd",
"count( distinct( vlt ) ) as macchine_giocanti"
],
"groupBy":"data_contabile",
"filter":" data_contabile between ${da} and ${a}
${filterByZone}",
"return":"macchineGiocanti"
}
40

41. Altre applicazioni di let
{
"type" : "let",
"if" : "${typologyReportResult[2]} > 0 ",
"target" : "${current}",
"value" : {
"cipupd" : "={ if( ( ${typologyReportResult[1]}
<> 0 ), eval(' ${current.cash_in} /
${typologyReportResult[0]}'), '' ) }"
}
}
41

42. OPLA e altri linguaggi
],
"end" : {
"type":"script",
"language":"Javascript",
"code":"
var actualPeriod = ctx.getVariable('$root.$actualPeriod');
if( actualPeriod != null && !actualPeriod.equals('undefined') ){
var block = ctx.getVariable('$root.$block');
var result = block.getParentBlock().getReturnValue();
if( result.size() > 0 ){
42

43. Un ultimo passaggio
• Il JSON viene processato dalla funzione
processResult della libreria orientdb-bi
• Verranno formattati header, body e footer
orientdb-bi
43

44. Il risultato
44

45. App: Archivio Commerciale
• Esigenza: informatizzare le visite delle sale
• Soluzione: OrientBI
– Command
– JS
– JQueryUI
Scheda Sala
Upload/Download file e foto
Aggiornamento DB
45

46. Come si presenta
46

47. Qualche dettaglio
47

48. Come si salvano i dati
rootObject = {
"@type" : "d",
"@class" : "VisiteSala",
"sala" : ridSala,
"data" : dataUTC,
"esercente" : esercente,
...
"vlt_piattaforma" : vlt_piattaforma
};
rootObject = db.save(rootObject);
if (db.getErrorMessage() == null) {
visitaList(ridSala);
} else
alert(db.getErrorMessage());
48

49. Alcuni dati salvati
EmbeddedMap
Collection
49

50. E le storie di vita vissuta?
• Local
• Indici
• Backup
• OPLA & Debug
• SNAPSHOT
• Aggregazioni
50

51. Robustezza(…) e velocità
Orient 1.4 = Local + MVRB-Tree
51

52. Quali inconvenienti?
• Riavvio improvviso della macchina:
– Ricostruzione degli indici
– Possibili record corrotti (tipicamente si
danneggia la tabella di allocazione dei record
sul disco risultando enormi >> 1GB)
• Riavvio normale del server Orient:
– Possibile flush non completo su disco
(prevalentamente con il kill del processo)
• Possibili record danneggiati
• Possibili indici inaffidabili
• In sostanza i normali problemi del Memory
Mapping!
52

53. Come correggere i danni?
Come si ricostruisce una città dopo il passaggio di Godzilla?
Solo avendo una città di backup!
53

54. Ripristino dei dati
• Il backup è affidabile?
– Se il db è integro si
– E’ lento (di fatto è un processo di export e
import)
– E’ estremamente lento in caso di record
corrotti
54

55. OPLA & Debug
• NON esiste
• Si passa per i breakpoint su IDE…
• C’è un poc realizzato da @ldellaquila di una
versione OrientBI 2.0 dove è possibile
impostare i breakpoint sui blocchi OPLA da
IDE web
55

56. Quando sarà rilasciato?
• Solo lui ci può rispondere…
56

57. Dalla 1.4 alla 1.7
• Local vs Plocal
• Wal
• MVRB-Tree vs SBTree, Hash & Lucene
• Backup migliorato
• Clustering multimaster
• Sharding
• Lucene
• …
• Più funzionalità
• Più stabilità
57

58. Come è andata?
58

59. Tutto ok?
• Gli indici non sono ancora dentro il WAL
• Con grandi db la ricostruzione è lenta (anche 11
ore!)
• Nel caso di indici compositi se nella query non
è presente la prima property non avremo
nessun risultato (usare più indici)
• Parser sql…
• Ottimizzatore query non sempre ottimizza…
• Complessa la parte di debug (explain, yourkit*,
etc…)
• Serializzazione…
59

60. RoadMap 2.0
60
• Protocollo binario (3x – 20x)
• Indici nel WAL
• Improvement Multicore
• Visualizzazione dei grafi su Studio
• Altro…

61. Per il futuro?
61

62. Lavorare con le SNAPSHOT
• Perché?
– Per avere sempre l’ultima versione
– Per avere subito delle modifiche ad hoc utilizzando solo
GIT
• Perché no? (tutto quello che è successo e nessuno lo ha mai detto…)
– Perché all’improvviso chiunque potrebbe inserire una
feature che non permette più di aprire il db
– Perché all’improvviso si potrebbe rendere necessario
esportare e importare tutto
– Perché all’improvviso alcune convenzioni potrebbero
cambiare in maniera sostanziale
– Perché all’improvviso i nuovi indici potrebbero non
essere più affidabili
– Perché i sistemi di debug potrebbero non funzionare*
– Perché non si dovrebbe fare e basta!
62

63. Sinergie
• Lavorare con le SNAPSHOT permette una
scoperta e una soluzione dei bug molto
rapida (con il team di Orient)
• Gli indici sono migliorati in maniera
importante (la ricostruzione è passata da 300 r/s
a 20.000 r/s senza più heap dump)
• Sono state aggiunte molte nuove
funzionalità
63

64. Le aggregazioni
• Nuova richiesta: velocizzare il report più usato
• Visualizza tutti i giorni, settimane, mese e anni
presenti sul db (a seconda della scelta)
• Raggruppa ogni volta real time
• Esegue e unisce i risultati delle query eseguite
su 2 classi: da 2.000.000 e da 8.000.000 di
record
• I raggruppamenti settimanali e mensili sono i
più usati
64

65. BI = Aggregazioni
• Una soluzione è creare altre classi che
gestiscono i dati aggregati.
• Vantaggi:
– Facile implementazione (OFunction in fase
di import)
– Pochi dati da gestire
• Svantaggi:
– Problemi di coerenza da una classe
all’altra
– Moltiplicazione degli indici
65

66. Dov’è la parte graph?
• Nei flussi che contengono tutte le
transazioni è stato seguito un approcio
diverso: legare le date ad un grafo
temporale
Anno
Mese
Settimana
Giorno Ora
Minuti
Secondi
Record
Record
Record
66

67. Meglio degli indici?
• Gli indici sono un albero bilanciato (che è
un tipo di grafo), quindi sono quasi
equivalenti
• Performance sulle aggregazioni non
accettabili (su classi da centinaia di milioni di
dati)
• Perché è stato sviluppato?
• Per sopperire agli indici allora immaturi
67

68. Come ottimizzare le ricerche
Anno
Mese
Settimana
Giorno Ora
Minuti
Secondi
RecordRecord
Record
Aggr AggrAggrAggr
Aggr
AggrAggr
n x 12
n
Aggr
68

69. Quante dimensioni?
• Tipicamente temporale o temporale x
territoriale
• Limite = n
69

70. Tutto rose e fiori?
• Punti di attenzione:
– Dimensioni del db
– Transazionalità delle aggregazioni per
evitare inconsistenza da un livello più
basso ad uno più alto
– E’ più efficiente del connubio indici x
classi?
Probabilmente no!
70

71. Quando è più indicato il graph?
• Utilizzare il grafo quando il costo di
aggregazione è maggiore di quello di ricerca
out().in()
71

72. Continueremo ad usare Orient?
• Si perché:
– In molti casi offre notevoli vantaggi
rispetto ad un relazionale e rispetto alla
concorrenza
– Perché la 1.7 è un prodotto maturo e la
2.0 sarà ancora più performante
– Perché se il cliente cambia i requisiti
dopo 18 mesi in produzione con poco
effort si può cambiare un’applicazione 
72

73. Feedback
Insomma parafrasando Edward Norton
‘’Orient spacca!’’
73

74. Grazie
luca.bianconi@assetdata.it

75. #AssetCercaCollaboratori
jobs@assetdata.it
75