Monica Franceschini - Frutto dell’esperienza diretta su due grossi progetti Big Data, in ambiti diversi e con finalità differenti, in questo speech metterò in evidenza le similitudini architetturali riscontrate. Entrambi infatti si basano su Apache Spark per il processing layer e su Hbase come storage. Analizzeremo le motivazioni e cercheremo di individuare i cardini architetturali su cui poggiano, cercando di interpretare le nuove tendenze, quali l’avvento di Kudu in Cloudera e le soluzioni più leggere basate su Spark +NoSQL.

1. Evoluzioni architetturali a partire da
Hadoop
Monica Franceschini
Solution Architecture Manager
Big Data Competency Center
Engineering Group

2. Esperienze
ENERGY
Raccolta coordinate geo-
spaziali da sensori di
localizzazione per analisi
predittive.
FINANCE
Realizzazione architettura
big data per applicazione
di CRM avanzato.
Gestione delle misure di
consumo elettrico di
15 milioni di utenti
P.A.

3. Energy
HDFS
Kafka
Hbase
Spark
Flume
Phoenix
Tecnologie Usate su
Hadoop
sistemiesterni
JMS
FS
flume
HDFS
kafkaHBase KAFKA
Spark Spark
streaming
Phoenix
Web apps
RDBMS
sqoop

4. Finance
NFS
Hbase
Spark
Phoenix
Tecnologie Usate su
Hadoop
sistemiesterni
NFS
HBase
Spark
Phoenix
Web apps
HDFS

5. P.A.
HDFS
Hbase
Spark
Spark MLlib
Flume
Phoenix
Tecnologie Usate su
Hadoop
sistemiesterni
JMS
flume
HDFS
HBase
Spark
Phoenix
Web apps
Spark
MLlib

6. I dati:
Molti dati (piccoli files
provenienti da sensori
o dati strutturati) di
piccole dimensioni

7. Ingestion:
Fast data
Event driven
Near real-time

8. Storage:
Modificare i singoli
record

9. Considerazioni
Scenari molto simili:
Flume, HBase & Spark
Online
performances
HBase invece
di HDFS
Dati con
caratteristiche
simili
High
throughput

10. Inoltre…
• Appoggiarsi a soluzione consolidata
• Possibilità di richiesta supporto
• Versione community o open source o …gratis!

11. Lo storage di Hadoop
HBaseHDFS
Large data sets
Unstructured data
Write-once-read-many access
Append-only file system
Hive HQL access
High-speed writes
and scans
Fault-tolerant
Replication
Many rows/columns
Compaction
Random read-writes
Updates
Rowkey access
Data modeling
NoSQL
Untyped data
Sparse schema
High throughput
Variable columns

12. La soluzione
HBase
Random read-writes
Updates
Compaction
Granular data
STORAGE

13. Problemi:

14. Alcune caratteristiche di HBase
• Esiste 1 solo indice o primary key
• Rowkey composta da vari campi
• Meno tabelle e più grandi (denormalizzate)
• Partizionamento orizzontale su rowkey
• Fondamentale il disegno e la progettazione della rowkey e lo
schema delle tabelle (data modeling)
• L’ access pattern deve essere noto a priori!

15. Warning!!!
Trattare HBase come un
database relazionale porta
a sicuro fallimento!!!

16. Cosa manca?
• SQL language
• Query analitiche
• Secondary index
Performances
per online
applications

17. Soluzioni:

18. • Phoenix is fast: una full table scan di 100M (milioni) di righe di solito impiega 20 sec
(cluster e tabelle di dimensioni medie) e questo scende a pochi millisecondi se la
query contieni filtri sulle colonne chiave.
• Porta il calcolo vicino al dato usando:
• coprocessors per effettuare operazioni minimizzando il trasferimento di dati
client/server
• custom filters e native HBase APIs
• Query chunks: Phoenix spezzetta la query ed esegue i pezzi in parallelo sul client,
usando un numero configurabile di thread. L’aggregazione viene fatta server-side
dai coprecessors

19. • OLTP
• Query analitiche
• Specifico per Hbase
• Lightweight
• Chi lo usa?

20. • Query engine + metadata store + JDBC driver
• Database su HDFS (ideale per bulk loads e queries che fanno
full-table scans)
• Usa le Api HBase (non accede direttamente a HFiles)
• …e le performances?…
Query: select count(1) from table over 1M and 5M
rows. Data is 3 narrow columns. Number of Region
Server: 1 (Virtual Machine, HBase heap: 2GB,
Processor: 2 cores @ 3.3GHz Xeon)

21. • Query engine + metadata store + JDBC driver
• DWH su HDFS
• Esegue jobs MapReduce anche per interrogare HBase
• Usa StorageHanlder per leggere HBase
• …e le performances?…
Query: select count(1) from table over 10M and
100M rows. Data is 5 narrow columns. Number
of Region Servers: 4 (HBase heap: 10GB,
Processor: 6 cores @ 3.3GHz Xeon)

22. • Cassandra + Spark come lightweight solution (sostitutiva di
Hbase+ Spark)
• Linguaggio SQL-like (CQL) +secondary indexes
• …e gli altri tools dell’ecosistema Hadoop?...

23. • Converged data platform: batch+NoSQL+streaming
• MapR-FS: ottimo throughput e gestisce bene files di ogni
dimensioni + updates puntuali
• Apache Drill come SQL-layer su Mapr-FS
• …è una soluzione proprietaria…

24. • Sviluppato da Cloudera ma Open Source (->Integrato con
Hadoop Ecosystem)
• Low-latency random access
• Super-fast Columnar Storage
• Designed for Next-Generation Hardware (storage basato su IO
di solid state drives + implementazione della cache
sperimentale)
• …è in beta version…
With Kudu, Cloudera promises to solve Hadoop's infamous
storage problem
InfoWorld | Sep 28, 2015

25. HBaseHDFS
Lo storage di Hadoop
highly scalable in-memory
database per MPP workloads
Fast writes, fast updates,
fast reads, fast everything
Structured data
SQL+scan use cases
Unstructured data
Deep storage
Fixed column schema
SQL+scan use cases
Any type column
schema
Gets/puts/micro
scans

26. Conclusioni
• Non esiste una sola soluzione
tecnologica, che soddisfi tutti i
requisiti
• L’opportunità di adottare soluzioni
Open Source dipende dal contesto
• Tecnologie sempre in evoluzione
• Che fare?
• REQUISITI
• NO LOCK-IN
• PEER-REVIEWS

27. Grazie!
Monica Franceschini
Twitter  @twittmonique
Linkedin  mfranceschini
Skype  monica_franceschini
Email  monica.franceschini@eng.it