L'utilizzo di Pig/Hive per l'elaborazione dei dati invece della mappa java diretta riduce il codice?

Question

(ancor più fondamentale di Difference between Pig and Hive? Why have both?)

Ho una pipeline di elaborazione di dati scritti in diversi Java mappa-ridurre compiti oltre Hadoop (il mio codice personalizzato, derivati ​​da Mapper di Hadoop e riduttore). È una serie di operazioni di base come join, inverse, sort e group by. Il mio codice è coinvolto e non molto generico.

Quali sono i pro e i contro del proseguimento di questo approccio che richiede un elevato sviluppo di sviluppo rispetto alla migrazione di tutto a Pig/Hive con diverse UDF? quali lavori non sarò in grado di eseguire? subirò un degrado delle prestazioni (lavorando con 100s di TB)? perderò la capacità di modificare e correggere il mio codice durante la manutenzione? sarò in grado di eseguire la pipeline di parte dei lavori come Java map-ridurre e utilizzare il loro input-output con i miei lavori Pig/Hive?

Answer 1

Riferimento Twitter: in genere uno script Pig è il 5% del codice di mappa nativa/riduci scritto in circa il 5% delle volte. Tuttavia, le query richiedono in genere tra il 110-150% del tempo necessario per eseguire una mappa nativa/ridurre il lavoro. Ma ovviamente, se esiste una routine che è altamente sensibile alle prestazioni, ha comunque la possibilità di codificare manualmente la mappa nativa/ridurre direttamente le funzioni.

Il riferimento di cui sopra parla anche di vantaggi e svantaggi di Pig rispetto allo sviluppo di applicazioni in MapReduce.

Come con qualsiasi linguaggio di livello superiore o astrazione, la flessibilità e le prestazioni vengono perse con Pig/Hive a scapito della produttività degli sviluppatori.

Answer 2

In questo paper a partire dal 2009 si afferma che Pig esegue 1,5 volte più lentamente di MapReduce. Si prevede che gli strumenti di livello superiore costruiti su Hadoop abbiano prestazioni più lente rispetto a MapReduce, tuttavia è vero che per poter eseguire MapReduce in modo ottimale è necessario un utente avanzato che scrive molto codice boilerplate (ad esempio comparatori binari).

Trovo pertinente menzionare una nuova API denominata Pangool (di cui sono uno sviluppatore) che punta a sostituire la semplice API Hadoop MapReduce rendendo molte più facili da codificare e comprendere (tipo secondario, riduzione- join laterali). Pangool non impone un overhead delle prestazioni (appena il 5% dal suo first benchmark) e conserva tutta la flessibilità dell'API MapRed originale.