Évaluation et comparaison de Hadoop pour des considérations de conception de l'intelligence commerciale

Question

Je compte diverses technologies pour l'entreposage de données et l'intelligence des entreprises et sont venus sur cet outil radical appelé Hadoop. Hadoop ne semble pas être parfaitement construite pour la BI, mais il y a des références de potentiel dans ce domaine. ( http://www.infoworld.com/d/ Data-Explosion / Hadoop-Business-business-Intelligence-488 ).

Cependant, peu d'informations que j'ai reçues d'Internet, mon intestin me dit que Hadoop peut devenir une technologie perturbatrice dans l'espace des solutions de BI traditionnelles. Il y a vraiment des informations clairsemées sur ce sujet, et je voulais donc rassembler toutes les pensées de Gourou ici sur le potentiel de Hadoop en tant qu'outil de BI, par rapport à l'infrastructure de BI bidon traditionnelle comme Oracle Exadata, Vertica etc . Pour commencer, je voudrais poser la question suivante -

• Considérations de conception - Comment concevoir une solution bi avec Hadoop soit différente des outils traditionnels? Je sais que cela devrait être différent, car je lis, on ne peut pas créer de schémas dans Hadoop. Je lis également qu'un avantage majeur sera l'élimination complète des outils de l'ETL pour Hadoop (est-ce vrai?) Avons-nous besoin de Hadoop + Pig + Mahout pour obtenir une solution BI ??

  Merci et salutations!

  Edit - décomposition dans plusieurs questions. Va commencer par celui que je pense plus Imp.

Answer 1

Hadoop est un excellent outil pour faire partie d'une solution BI. Ce n'est pas lui-même une solution BI. Qu'est-ce que Hadoop est effectué dans data_a et sorties data_b. Tout ce qui est nécessaire pour BI mais qui n'est pas sous une forme utile peut être traité à l'aide de MapReduce et de produire une forme utile des données. Soyez CSV, Hive, HBASE, MSSQL ou autre chose d'autre utilise pour afficher les données.

Je crois que Hadoop est censé être l'outil ETL. C'est ce que nous utilisons pour. Nous traitons les concerts de fichiers journaux toutes les heures et stockons-le dans la ruche et effectuons des agrégations quotidiennes qui se chargent dans un serveur MSSQL et visualisées via une couche de visualisation.

Les principales considérations de conception que j'ai couru sont:

- Données flexibilité: Voulez-vous que vos utilisateurs affichaient des données pré-agrégées ou ont la flexibilité nécessaire pour ajuster la requête et regarder les données comment elles veulent
- Vitesse: Combien de temps voulez-vous que vos utilisateurs attendent les données? La ruche (par exemple) est lente. Il faut quelques minutes pour générer des résultats, même sur des ensembles de données assez petits. Plus les données sont grandies, plus il faudra pour générer un résultat.
- Visualisation: Quel type de visualisation voulez-vous utiliser? Voulez-vous personnaliser de nombreuses pièces ou être capable d'utiliser quelque chose hors de l'étagère? Quelles contraintes et quelle flexibilité sont nécessaires pour votre visualisation? Quelle est la flexibilité et la modification de la visualisation?

htth

mise à jour: en réponse au commentaire de @ Bhat, question de manque de visualisation ...
L'absence d'un outil de visualisation qui nous permettrait d'utiliser efficacement les données stockées dans HBASE était un facteur majeur de la réévaluation de notre solution. Nous avons stocké les données brutes dans la ruche et avons pré-agrégé les données et le stocké HBASE. Pour utiliser cela, nous allions devoir écrire un connecteur personnalisé (cette partie) et la couche de visualisation. Nous avons examiné ce que nous serions en mesure de produire et de ce qui est disponible dans le commerce et est allé la route commerciale.
Nous utilisons toujours Hadoop comme outil ETL pour traiter nos blogs, c'est fantastique pour cela. Nous venons d'envoyer les données brutes ETL'D à une base de données de données commerciale qui prendra la place de la HIVE et de la HBASE dans notre conception.

Hadoop ne se comparait pas vraiment à MSSQL ou à un autre stockage de l'entrepôt de données. Hadoop ne fait aucun stockage (ignorant les HDFS), le traitement des données. Exécution de MapRéduces (quelle ruche) va être plus lente que MSSQL (ou telle).

Answer 2

Hadoop est très bien adapté pour stocker des fichiers colossaux pouvant représenter des tables de fait.Ces tables peuvent être partitionnées en plaçant des fichiers individuels représentant la table dans des répertoires distincts.La ruche comprend ces structures de fichiers et permet de les interroger comme des tables partitionnées.Vous pouvez formuler vos questions de BI aux données Hadoop sous la forme de requêtes SQL via la ruche, mais vous aurez toujours besoin d'écrire et d'exécuter un travail de MapReduce occasionnel.

Answer 3

Du point de vue des affaires, vous devriez envisager Hadoop Si vous avez beaucoup de données de faible valeur.Il existe de nombreux cas lorsque les solutions RDBMS / MPP ne sont pas rentables. Vous devriez également envisager Hadoop comme une option grave si vos données ne sont pas structurées (HTML par exemple).

Answer 4

Nous créons une matrice de comparaison pour les outils BI pour Big Data / Hadoop http://hadoopilluminé.com/hadoop_book/bi_tools_for_hadoop.html

C'est le travail en cours et aimerait toute entrée.

(Disclaimer: Je suis l'auteur de ce livre en ligne)