Date post: | 11-Jan-2017 |
Category: |
Technology |
Upload: | data-driven-innovation |
View: | 113 times |
Download: | 2 times |
Evoluzioni architetturali a partire da Hadoop
Monica FranceschiniSolution Architecture Manager
Big Data Competency CenterEngineering Group
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.
Energy
HDFSKafkaHbaseSparkFlumePhoenix
Tecnologie Usate su Hadoop sistem
i esterni
JMS
FS
flume
HDFS
kafka
HBase KAFKA
Spark Sparkstreaming
Phoenix
Web apps
RDBMS
sqoop
Finance
NFSHbaseSparkPhoenix
Tecnologie Usate su Hadoop sistem
i esterni
NFS
HBase
Spark
Phoenix
Web apps
HDFS
P.A.
HDFSHbaseSparkSpark MLlibFlumePhoenix
Tecnologie Usate su Hadoop sistem
i esterni
JMS flume
HDFS
HBase
Spark
Phoenix
Web apps
SparkMLlib
I dati:
Molti dati (piccoli files provenienti da sensori o dati strutturati) di piccole dimensioni
Ingestion:
Fast data Event drivenNear real-time
Storage:
Modificare i singoli record
Considerazioni
Scenari molto simili:Flume, HBase & Spark
Online performances
HBase invecedi HDFS
Dati con caratteristiche
simili
Highthroughput
Inoltre…
• Appoggiarsi a soluzione consolidata• Possibilità di richiesta supporto• Versione community o open source o …gratis!
Lo storage di Hadoop
HBaseHDFS
Large data setsUnstructured dataWrite-once-read-many access Append-only file systemHive HQL accessHigh-speed writes
and scansFault-tolerantReplication
Many rows/columnsCompactionRandom read-writesUpdatesRowkey accessData modelingNoSQLUntyped data Sparse schemaHigh throughputVariable columns
La soluzione
HBaseRandom read-writes
UpdatesCompaction
Granular data
STORAGE
Problemi:
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!
Warning!!!
Trattare HBase come un database relazionale porta a sicuro
fallimento!!!
Cosa manca?
• SQL language• Query analitiche• Secondary index
Performancesper online
applications
Soluzioni:
• 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
• OLTP• Query analitiche• Specifico per Hbase• Lightweight• Chi lo usa?
• 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)
(on Hbase)
• Query engine + metadata store + JDBC driver• DWH su HDFS • Esegue jobs MapReduce anche per interrogare HBase• Usa StorageHanlder per leggere HBase• …e le performances?…
(on Hbase)
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)
• Cassandra + Spark come lightweight solution (sostitutiva di Hbase+ Spark)
• Linguaggio SQL-like (CQL) +secondary indexes• …e gli altri tools dell’ecosistema Hadoop?...
KafkaFLUME
Sqoop
HDFS
NFS
Oozie
Pig
Storm
• 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…
• 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 problemInfoWorld | Sep 28, 2015
HBaseHDFS
Lo storage di Hadoop
highly scalable in-memory database per MPP workloads
Fast writes, fast updates, fast reads, fast everything
Structured dataSQL+scan use cases
Unstructured dataDeep storage
Fixed column schemaSQL+scan use cases
Any type column schema
Gets/puts/micro scans
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
Grazie!
Monica FranceschiniTwitter @twittmoniqueLinkedin mfranceschini
Skype monica_franceschiniEmail [email protected]