Valutare e confrontare Hadoop per le considerazioni sulla progettazione di business intelligence

Question

Sto prendendo in considerazione varie tecnologie per i data warehousing e la business intelligence e ho incontrato questo strumento radicale chiamato Hadoop. Hadoop non sembra essere esattamente costruito per scopi BI, ma ci sono riferimenti che hanno un potenziale in questo campo. ( http://www.infoworld.com/d/data-explosion/hadoop-pitched-business-intelligence-488).

Tuttavia poche informazioni che ho ricevuto da Internet, il mio intestino mi dice che Hadoop può diventare una tecnologia dirompente nello spazio delle tradizionali soluzioni BI. Ci sono davvero informazioni scarse su questo argomento, e quindi volevo raccogliere tutti i pensieri del guru qui sul potenziale di Hadoop come strumento BI rispetto alle tradizionali infrastrutture BI backend come Oracle Exadata, Vertica ecc.. Per cominciare, vorrei porre la seguente domanda -

• considerazioni sul design - In che modo la progettazione di una soluzione BI con Hadoop sarebbe diversa dagli strumenti tradizionali? So che dovrebbe essere diverso, poiché leggo non si possono creare schemi in Hadoop. Ho anche letto che un grande vantaggio sarà la completa eliminazione degli strumenti ETL per Hadoop (è vero?) Abbiamo bisogno di Hadoop + Pig + Mahout per ottenere una soluzione BI ??

Grazie e saluti!

EDIT - Abbasso in più domande. Inizierà con quello che penso la maggior parte dell'imp.

Answer 1

Hadoop è un ottimo strumento per far parte di una soluzione BI. Non è di per sé una soluzione BI. Ciò che Hadoop fa è prendere in data_a e subita data_b. Qualunque cosa sia necessaria per BI ma non è in una forma utile può essere elaborato utilizzando MapReduce e produrre una forma utile dei dati. Che si tratti di CSV, Hive, Hbase, MSSQL o qualsiasi altra cosa utilizzata per visualizzare i dati.

Credo che Hadoop dovrebbe essere lo strumento ETL. Questo è quello per cui lo stiamo usando. Elaboriamo concerti di file di registro ogni ora e lo memorizziamo in alveare e facciamo aggregazioni giornaliere che si stanno caricando in un server MSSQL e visualizzati attraverso un livello di visualizzazione.

Le principali considerazioni di progettazione contro cui ho organizzato sono:
- Flessibilità dei dati: Vuoi che i tuoi utenti visualizzino i dati pre-aggregati o abbiano la flessibilità per regolare la query e guardare i dati come desiderano
- Velocità: Quanto tempo vuoi che i tuoi utenti aspettino i dati? L'alveare (per esempio) è lento. Ci vogliono minuti per generare risultati, anche su set di dati abbastanza piccoli. Maggiore è i dati attraversati più a lungo ci vorranno per generare un risultato.
- Visualizzazione: Che tipo di visualizzazione vuoi usare? Vuoi costruire molti pezzi o essere in grado di usare qualcosa dallo scaffale? Quali restrizioni e flessibilità sono necessarie per la tua visualizzazione? Quanto deve essere flessibile e mutevole la visualizzazione?

hth

Aggiornare: Come risposta al commento di @Bhat che chiede di mancanza di visualizzazione ...
La mancanza di uno strumento di visualizzazione che ci consentirebbe di utilizzare efficacemente i dati memorizzati in HBase è stata un fattore importante nel rivalutare la nostra soluzione. Abbiamo memorizzato i dati grezzi in alveare, pre-aggregato i dati e archiviato HBase. Per utilizzare questo avremmo dovuto scrivere un connettore personalizzato (ha fatto questa parte) e il livello di visualizzazione. Abbiamo esaminato ciò che saremmo stati in grado di produrre e ciò che è disponibile in commercio e abbiamo preso il percorso commerciale.
Usiamo ancora Hadoop come strumento ETL per l'elaborazione dei nostri weblog, è fantastico per questo. Inviamo solo i dati RAW ETL'D a un database commerciale di big data che prenderà il posto di Hive e HBase nel nostro design.

Hadoop non è in realtà paragonabile a MSSQL o altra archivio di data warehouse. Hadoop non esegue alcuna memoria (ignorando gli HDF), elabora i dati. L'esecuzione di MapReduces (cosa che fa Hive) sarà più lento di MSSQL (o tale).

Answer 2

Hadoop è molto adatto per la memorizzazione di file colossali che possono rappresentare tabelle di fatti. Queste tabelle possono essere partizionate posizionando singoli file che rappresentano la tabella in directory separate. Hive comprende tali strutture di file e consente di interrogarle come tabelle partizionate. Puoi definire le tue domande BI ai dati Hadoop sotto forma di query SQL tramite Hive, ma dovrai comunque scrivere ed eseguire un lavoro mapReduce occasionale.

Answer 3

Dal punto di vista aziendale, dovresti considerare Hadoop se hai molti dati di basso valore. Esistono molti casi in cui le soluzioni RDBMS / MPP non sono convenienti. Dovresti anche considerare Hadoop come un'opzione seria se i tuoi dati non sono strutturati (ad esempio HTML).

Answer 4

Stiamo creando una matrice di confronto per gli strumenti BI per Big Data / Hadoophttp://hadoopilluminated.com/hadoop_book/bi_tools_for_hadoop.html

È un lavoro in corso e amerebbe qualsiasi input.

(Disclaimer: sono l'autore di questo libro online)