Différence entre cochon et ruche ? Pourquoi avoir les deux ?

Question

Mon parcours - 4 semaines dans le monde Hadoop. J'ai un peu tâté de Hive, Pig et Hadoop en utilisant la VM Hadoop de Cloudera. J'ai lu le document de Google sur Map-Reduce et GFS ( Lien PDF ).

Je comprends que

• Le langage du cochon Le latin du cochon est un changement de (convient à la façon dont les programmeurs pensent) Le style de programmation déclaratif de type SQL déclaratif de programmation et le langage de requête de Hive ressemble beaucoup à SQL.

• Pig se trouve au-dessus de Hadoop et, en principe, il peut également être installé au-dessus de Dryad. Je peux me tromper mais Hive est étroitement couplé à Hadoop.

• Les commandes Pig Latin et Hive se compilent en tâches Map et Reduce.

Ma question - Quel est l'objectif d'avoir les deux quand un seul (disons Pig) pourrait faire l'affaire. Est-ce simplement parce que Pig est évangélisé par Yahoo ! et Hive par Facebook ?

Answer 1

Regarde ça poste d'Alan Gates, architecte Pig chez Yahoo !, qui compare les cas où il faudrait utiliser un SQL comme Hive plutôt que Pig. Il présente des arguments très convaincants quant à l'utilité d'un langage procédural comme Pig (par rapport à un SQL déclaratif) et son utilité pour les concepteurs de flux de données.

Answer 2

Hive a été conçu pour s'adresser à une communauté à l'aise avec SQL. Sa philosophie était que nous n'avions pas besoin d'un énième langage de script. Hive prend en charge les scripts de transformation map et reduce dans le langage du choix de l'utilisateur (qui peuvent être intégrés dans des clauses SQL). Il est largement utilisé chez Facebook par des analystes à l'aise avec SQL ainsi que par des mineurs de données programmant en Python. Les efforts de compatibilité SQL dans Pig ont été abandonnés AFAIK - la différence entre les deux projets est donc très claire.

La prise en charge de la syntaxe SQL signifie également qu'il est possible de s'intégrer à des outils de BI existants comme Microstrategy. Hive dispose d'un pilote ODBC/JDBC (en cours de développement) qui devrait permettre cette intégration dans un avenir proche. Il commence également à prendre en charge les index, ce qui devrait permettre la prise en charge des requêtes de type "drill-down", courantes dans ce type d'environnement.

Enfin, et ce n'est pas directement lié à la question, Hive est un cadre permettant d'effectuer des requêtes analytiques. Bien que son utilisation principale soit l'interrogation de fichiers plats, il n'y a aucune raison pour qu'il ne puisse pas interroger d'autres magasins. Actuellement, Hive peut être utilisé pour interroger des données stockées dans Hbase (qui est un magasin clé-valeur comme ceux que l'on trouve dans les entrailles de la plupart des SGBDR), et le projet HadoopDB a utilisé Hive pour interroger un niveau de SGBDR fédéré.

Answer 3

C'est celui qui m'a le plus aidé (bien qu'il date d'un an). http://yahoohadoop.tumblr.com/post/98256601751/pig-and-hive-at-yahoo

Il parle spécifiquement de Pig vs Hive et de quand et où ils sont employés chez Yahoo. J'ai trouvé cela très instructif. Quelques notes intéressantes :

Sur les changements incrémentiels/mises à jour des ensembles de données :

Au lieu de cela, la jointure avec les nouvelles données incrémentales et l'utilisation des résultats avec ceux de la jointure complète précédente. l'approche correcte. Cette opération ne prendra que quelques minutes. Les opérations standard de base de données peuvent être implémentées de cette manière incrémentale en Pig Latin, ce qui fait de Pig un bon outil pour ce cas d'utilisation.

Sur l'utilisation d'autres outils via le streaming :

L'intégration de Pig avec le streaming permet également aux chercheurs de chercheurs de prendre un script qu'ils ont déjà débogué sur un petit ensemble de données et de l'exécuter sur un énorme ensemble de données.

L'utilisation de Hive pour l'entreposage de données :

Dans les deux cas, le modèle relationnel et SQL sont les mieux adaptés. En effet, l'entreposage de données a été l'un des principaux cas d'utilisation de SQL pendant une grande partie de son histoire. Il possède les bonnes constructions pour supporter les types de requêtes et d'outils que les analystes veulent utiliser. de requêtes et d'outils que les analystes veulent utiliser. Et il est déjà utilisé Et il est déjà utilisé à la fois par les outils et les utilisateurs sur le terrain.

Le sous-projet Hadoop Hive fournit une interface SQL et un modèle relationnel pour Hadoop. pour Hadoop. L'équipe Hive a commencé à travailler à l'intégration avec des outils de BI via des interfaces telles que ODBC. via des interfaces telles que ODBC.

Answer 4

Je pense que la vraie réponse à votre question est qu'il s'agit/était de projets indépendants et qu'il n'y avait pas d'objectif coordonné de manière centralisée. Ils se trouvaient dans des espaces différents au début et ont fini par se chevaucher avec le temps, à mesure que les deux projets se développaient.

Paraphrase du livre Hadoop O'Reilly :

Pig : un langage de flux de données et un environnement pour l'exploration de très grands ensembles de données.

Hive : un entrepôt de données distribué

Answer 5

Vous pouvez obtenir des résultats similaires avec les requêtes Pig/Hive. La principale différence réside dans l'approche de la compréhension/écriture/création des requêtes.

Pig a tendance à créer un flux de données : de petites étapes où, dans chacune d'entre elles, vous effectuez un traitement.
Hive vous offre un langage de type SQL pour opérer sur vos données, de sorte que la transformation à partir d'un SGBDR est beaucoup plus facile (Pig peut être plus facile pour quelqu'un qui n'a pas d'expérience préalable avec SQL).

Il est également intéressant de noter que pour Hive, vous disposez d'une interface agréable pour travailler avec ces données (Beeswax pour HUE, ou l'interface web de Hive), et qu'il vous offre également un métastore pour les informations sur vos données (schéma, etc.) qui est utile comme information centrale sur vos données.

J'utilise à la fois Hive et Pig, pour des requêtes différentes (j'utilise celui qui me permet d'écrire une requête plus rapidement/plus facilement, je le fais de cette façon pour la plupart des requêtes ad-hoc) - ils peuvent utiliser les mêmes données comme entrée. Mais actuellement, je fais une grande partie de mon travail avec Beeswax.