Cassandra + Hadoop: Analisi Batch con Apache Cassandra
•Als PPT, PDF herunterladen•
1 gefällt mir•1,230 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Cassandra + Hadoop: Analisi Batch con Apache Cassandra
Ähnlich wie Cassandra + Hadoop: Analisi Batch con Apache Cassandra (20)
Mehr von Jeremy Hanna
Mehr von Jeremy Hanna (12)
Cassandra + Hadoop: Analisi Batch con Apache Cassandra
- 1. Cassandra + Hadoop Analisi batch con Apache Cassandra
- 2. Apache Cassandra • Collezione di servers, un singolo database • Architettura semplice • Completamente distribuito • Replica efficacemente fra i datacenters • Fault tolerant • E’ un database realtime
- 5. Modellare I Dati • Siamo abituati ad SQL • Con Cassandra, si modellano i dati a seconda delle modalita’ di interrogazione • Un column family per ciascun tipo di interrogazione
- 6. Altre Caratteristiche • Fault tolerance • Si possono perdere nodi o datacenters interi • Ottimizzato per la scrittura dati • Eventual consistency • Si possono replicare i dati attraverso molti datacenters
- 7. Analisi Batch • Abbiamo molti dati • Vogliamo eseguire interrogazioni ed aggregazioni complesse sui dati • Che fare? • Hadoop! • Supporto per Hadoop da 2010 • Il JobTracker da i job verso nodi che hanno la suddivisione i dati
- 8. Workload Isolation • Nessuna interferenza con le interrogazioni realtime • Usiamo un datacenter per ogni workload • Ogni workload ha la sua copia dei dati
- 9. Usi Specifici Con Cassandra • Creare un nuovo modo di interrogare i dati • Validare i dati • Correggere i dati
- 10. Domande? • Jeremy Hanna • jeremy@datastax.com • @jeromatron (twitter e irc)
Hinweis der Redaktion
- Chi sono, un po’ riguardo a datastax, da quanto tempo lavoro con Cassandra e Hadoop
- Non ci sono ruoli speciali. Parliamo un po’ piu’ tardi riguardo al fault tolerance. Replicazione tra i datacenters - un nodo in ciascun datacenter agisce come coordinatore. Una coppia sola e’ mandata al altro datacenter e quel nodo replica i dati agli altri nodi. Cosi’ e’ piu efficace.
- Si puo vedere che ci sono piccole startups fino a grandi societa’ che usano Apache Cassandra. Io lavoro nel gruppo di supporto a DataStax, e quindi do aiuto a tante di queste societa’.
- Teorico, si puo scalare Cassandra linearmente ma e’ cosi’ in pratica? Netflix ha fatto delle prove con questo. Usa Cassandra in AWS ed ha sperimentato con vari numeri di nodi. Al Hadoop Summit in 2010, ho incontrato qualcuno da una grande societa’ in 2010. A quel tempo il suo gruppo usava un database Oracle per processare delle carte regalo, in particolare durante il periodo delle feste. Dalle proiezioni di crescita annuale, hanno scoperto che Oracle non avrebbe potuto sostenere il traffico dati delle successive festivitá. Quindi hanno ricercato vari databases alternativi e hanno scelto Cassandra.
- Un modo denormalizzato. Ad esempio, per il modello commune di tweets, si potrebbe avere un column family per i tweets, un altro per i seguaci, ecc. Per i dati della musica, si puo avere un column family che interroga da canzone id. Poi forse vuoi interrogare quegli stessi dati da album. Quello sarebbe un altro column family con o gli ids oppure tutti i dati delle canzoni - denormalizzato.
- Si possono perdere nodi individuali e anche datacenters completi senza disturbare la funzionalitá della sua applicazione, per sia lettura che scrittura.E’ sempre interessante parlando con le persone che usano Cassandra. L’altra sera, quando ero a una conferenza ad Amsterdam, qualcuno mi ha detto che uno dei loro quattro datacenters e’ andata giu per tre giorni durante una tempesta nel nord-est negli Stati Uniti. La loro applicazione non funzionava per soltanto quindici minuti, e quello non era la colpa di Cassandra. Non ci sono letture prima di scrivere. Si chiama append-only perché non si deve fare aggiornamenti a posto. Eventual consistency: supponiamo che abbiamo 3 datacenters, due negli Stati Uniti e uno in Europa. Supponiamo di voler replicare i dati 3 volte in ciascun datacenter. Con Cassandra possiamo decidere per ciascun operazione quanti nodi vogliamo consultare prima di ritornare successo alla nostra applicazione cliente. Se vogliamo fare un write al datacenter in Europa, possiamo usare il consistency level local_quorum. Questo scrive i dati in questo esempio a due nodi prima di respondere ad applicazione che tutto e’ bene. Allo stesso momento asynchronosamente, scrive alla terza replica in quel datacenter e alle repliche negli altri datacenters. In questo modo, possiamo aspettare servers soltanto in Europa prima di rispondere al server di applicazione in Europa. Se uno dei servers in Europa va giu’, o il WAN link va giu’, o anche un datacenter completo va giu, possiamo ancora scrivere a leggere i dati. Quando the cose ritornano a normale, i dati sono mandati alle altre repliche. Fa il suo migliore di avere consistency e corregge i dati automaticamente.
- Ad esempio, abbiamo dati di playlists, come fa Spotify con Cassandra. Vogliamo sapere quante persone hanno aggiunto canzoni dal nuovo album di David Bowie dopo e’ stato rilasciato. Forse dopo un po’ di pubblicita’. Forse volgiamo isolare la nostra ricerca a Calabria? Si puo fare con Hadoop.
- Forse abbiamo gia un column family per le canzoni ma forse mesi dopo vuoi avere un altro column family che vuoi interrogare da album id. Che fare? Hadoop anche puo aiutare in questo caso. Con 2 o 3 linee di code nella forma di un pig o hive script, si puo populare questo nuovo column family con questi dati. Forse abbiamo messo in produzione code che introduce errori nei nostri dati, or forse sospettiamo che e’ cosi’. Possiamo fare un piccolo script per poter validare i nostri dati. Forse abbiamo un column family per i tags per la musica. C’e’ un errore che mette un tag Death Metal su ogni nuova canzone. Che fare per correggere questo? Si puo usare un piccolo script per anche correggere i dati. Sta attento did non introdurre con questi piccoli script pero’. E’ facile causare molti danni ai dati cosi’.