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 monica.franceschini@eng.it